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CHAPTER  1 


INTRODUCTION 


The  Ada  implementation  described  above  was  tested  according  to  the  Ada 
Validation  Procedures  [Pro95]  against  the  Ada  Standard  [Ada83]  using  the 
current  Ada  Compiler  Validation  Capability  (ACVC)  *  This  Validation  Summary 
Report  (VSR)  gives  an  account  of  the  testing  of  this  Ada  implementation*  For 
any  technical  terms  used  in  this  report,  the  reader  is  referred  to  [Pro95]. 
A  detailed  description  of  the  ACVC  may  be  found  in  the  current  ACVC  User's 
Guide  [UG89] . 


1.1  USE  OF  THIS  VALIDATION  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the  Ada 
Certification  Body  may  make  full  and  free  pi±>lic  disclosure  of  this  report. 
In  the  United  States,  this  is  provided  in  accordance  with  the  “Freedom  of 
Information  Act“  (5  U.S.C.  #552).  The  results  of  this  validation  apply  only 
to  the  computers,  operating  systems,  and  compiler  versions  identified  in  this 
report . 

The  organizations  represented  on  the  signature  page  of  this  report  do  not 
2;epresent  or  warrant  that  all  statements  set  forth  in  this  report  are 
accurate  and  complete,  or  that  the  subject  implementation  has  no 
nonconformities  to  the  Ada  Standard  other  than  those  presented.  Copies  of 
this  report  are  available  to  the  public  from  the  AVF  which  performed  this 
validation  or  from: 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield  VA  22161 

Questions  regarding  this  report  or  the  validation  test  results  should  be 
directed  to  the  AVF  which  performed  this  validation  or  to: 

Ada  Validation  Organization 

Computer  and  Software  Engineering  Division 

Institute  for  Defense  Analyses 

1801  North  Beauregard  Street 

Alexandria  VA  22311-1772 
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1 . 2  REFERENCES 

[Adas 3]  Reference?  Manual  for  the  Ada  Programming  Language# 

ANSI/MIL-STD-1815A,  February  1983  and  ISO  8652-1987. 

[Pro95]  Ada  Comniler  Validation  Procedures.  Version  4.0,  Ada  Joint 
Program  Office,  January  1995. 

[UG89]  Ada  Compiler  Validation  Capability  User'?  Guide,  21  June  1989 


1.3  ACVC  TEST  CLASSES 

Compliance  of  Ada  implementations  is  tested  by  means  of  the  ACVC.  The  ACVC 
contains  a  collection  of  test  programs  structured  into  six  test  classes:  A, 
B,  C,  D,  E,  and  L.  The  first  letter  of  a  test  name  identifies  the  class  to 
which  it  belongs.  Class  A,  C,  D,  and  E  tests  are  executable.  Class  B  and 
class  L  tests  are  expected  to  produce  errors  at  compile  time  and  link  time, 
respectively. 

The  executable  tests  are  written  in  a  self-checking  manner  and  produce  a 
PASSED,  FAILED,  or  NOT  APPLICABLE  message  indicating  the  result  when  they  are 
executed.  Three  Ada  library  units,  the  packages  REPORT  and  SPPRT13,  and  the 
procedure  CHECK_FILE  are  used  for  this  purpose.  The  package  REPORT  also 
provides  a  set  of  identity  functions  used  to  defeat  some  compiler 
optimizations  allowed  by  the  Ada  Standard  that  would  circumvent  a  test 
objective.  The  package  SPPRT13  is  used  by  many  tests  for  Chapter  13  of  the 
Ada  Standard.  The  procedure  CHECK_FILE  is  used  to  check  the  contents  of  text 
files  written  by  some  of  the  Class  C  tests  for  Chapter  14  of  the  Ada 
Standard.  The  operation  of  REPORT  and  CHECK_FILE  is  checked  by  a  set  of 
executable  tests.  If  these  units  are  not  operating  correctly,  validation 
testing  is  discontinued. 

Class  B  tests  check  that  a  compiler  detects  illegal  language  usage.  Class  B 
tests  are  not  executable.  Each  test  in  this  class  is  compiled  and  the 
resulting  compilation  listing  is  examined  to  verify  that  all  violations  of 
the  Ada  Standard  are  detected.  Some  of  the  class  B  tests  contain  legal  Ada 
code  which  must  not  be  flagged  illegal  by  the  compiler.  This  behavior  is 
also  verified. 

Class  L  tests  check  that  an  Ada  implementation  correctly  detects  violation  of 
the  Ada  Standard  involving  multiple,  separately  compiled  units.  Errors  are 
expected  at  link  time,  and  execution  is  attempted. 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be  replaced  by 
implementation-specific  values  —  for  example,  the  largest  integer.  A  list 
of  the  values  used  for  this  implementation  is  provided  in  Appendix  A.  In 
addition  to  these  anticipated  test  modifications,  additional  changes  may  be 
required  to  remove  unforeseen  conflicts  between  the  tests  and 
implementation-dependent  characteristics.  The  modifications  required  for 
this  implementation  are  described  in  section  2.3. 
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For  each  Ada  implementation,  a  customized  test  suite  is  produced  by  the  AVF. 
This  customization  consists  of  making  the  modifications  described  in  the 
preceding  paragraph,  removing  withdrawn  tests  (see  section  2.1),  and  possibly 
removing  some  inapplicable  tests  (see  section  2.2  and  [UG89]). 

In  order  to  pass  an  ACVC  an  Ada  implementation  must  process  each  test  of  the 
customized  test  suite  according  to  the  Ada  Standard. 


1.4  DEFINITION  OF  TERMS 

Ada  Compiler  The  software  and  any  needed  hardware  that  have  to  be  added  to 
a  given  host  and  target  computer  system  to  allow 
transformation  of  Ada  programs  into  executable  form  and 
execution  thereof. 

Ada  Compiler  The  means  for  testing  compliance  of  Ada  implementations. 
Validation  consisting  of  the  test  suite,  the  support  programs,  the  ACVC 

Capability  user's  guide  and  the  template  for  the  validation  summary 

(ACVC)  report. 

Ada  An  Ada  compiler  with  its  host  computer  system  and  its 

Implementation  target  computer  system. 

Ada  Joint  The  part  of  the  certification  body  which  provides  policy  and 

Program  guidance  for  the  Ada  certification  system. 

Office  (AJPO) 

Ada  The  part  of  the  certification  body  which  carries  out  the 

Validation  procedures  required  to  establish  the  compliance  of  an  Ada 
Facility  (AVF)  implementation. 

Ada  The  part  of  the  certification  body  that  provides  technical 

Validation  guidance  for  operations  of  the  Ada  certification  system. 

Organization 
(AVO) 

Compliance  of  The  ability  of  the  implementation  to  pass  an  ACVC  version, 
an  Ada 

Imp 1 emen t  at i on 

Computer 
System 


A  functional  unit,  consisting  of  one  or  more  computers  and 
associated  software,  that  uses  common  storage  for  all  or  part 
of  a  program  and  also  for  all  or  part  of  the  data  necessary 
for  the  execution  of  the  program;  executes  user-written  or 
user-designated  programs;  performs  user-designated  data 

manipulation,  including  arithmetic  operations  and  logic 

operations;  and  that  can  execute  programs  that  modify 
themselves  during  execution.  A  computer  system  may  be  a 
stand-alone  unit  or  may  consist  of  several  inter-connected 
units . 
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Conformity 


Customer 


Declaration  of 
Conformance 


Host  Computer 
System 

Inapplicable 

test 

ISO 

LRM 


Operating 

System 


Target 

Computer 

System 

Validated  Ada 
Compiler 

Validated  Ada 
Implementation 

Validation 


Withdrawn 

test 


Fulfillment  by  a  product,  process,  or  service  of  all 
requirements  specified. 

An  individual  or  corporate  entity  who  enters  into  an  agreement 
with  an  AVF  which  specifies  the  terms  and  conditions  for  AVF 
services  (of  any  kind)  to  be  performed. 

A  formal  statement  from  a  customer  assuring  that  conformity^ 
is  realized  or  attainable  on  the  Ada  implemeitation  for  which 
validation  status  is  realized. 

A  computer  system  where  Ada  source  programs  are  transformed 
into  executable  form. 

A  test  that  contains  one  or  more  test  objectives  found  to  be 
irrelevant  for  the  given  Ada  implementation. 

International  Organization  for  Standardization. 

The  Ada  standard,  or  Language  Reference  Manual,  published  as 
ANSI/MIL-STD-1815A-1983  and  ISO  8652-1987.  Citations  from  the 
LRM  take  the  form  "<section>. <subsection>:<paragraph>. “ 

Software  that  controls  the  execution  of  programs  and  that 
provides  services  such  as  resource  allocation,  scheduling, 
input /output  control,  and  data  management.  Usually,  operating 
systems  are  predominantly  software,  but  partial  or  complete 
hardware  implementations  are  possible. 

A  computer  system  where  the  executable  form  of  Ada  programs 
are  executed. 


The  compiler  of  a  validated  Ada  implementation. 


An  Ada  implementation  that  has  been  validated  successfully 
either  by  AVF  testing  or  by  registration  [Pro95] . 

The  process  of  checking  the  conformity  of  an  Ada  compiler  to 
the  Ada  programming  language  and  of  issuing  a  certificate  for 
this  implementation. 

A  test  found  to  be  incorrect  and  not  used  in  conformity 
testing.  A  test  may  be  incorrect  because  it  has  an  invalid 
test  objective,  fails  to  meet  its  test  objective,  or  contains 
erroneous  or  illegal  use  of  the  Ada  programming  language. 
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IMPLEMENTATION  DEPENDENCIES 


2,1  WITHDRAWN  TESTS 

The  following  tests  have  been  withdrawn  by  the  AVO.  The  rationale  for 
withdrawing  each  test  is  available  from  either  the  AVO  or  the  A VF .  The 
publication  date  for  this  list  of  withdrawn  tests  is  22  November  1993. 


B27005A 

E28005C 

B28006C 

C32203A 

C34006D 

C35507K 

C35507L 

C35507N 

C35507O 

C35507P 

C35508I 

C35508J 

C35508M 

C35508N 

C35702A 

C35702B 

C37310A 

B41308B 

G43004A 

C45114A 

C45346A 

C45612A 

C45612B 

C45612C 

C45651A 

C46022A 

B49008A 

B49008B 

A54B02A 

C55B06A 

A74006A 

C74308A 

B83022B 

B83022H 

B83025B 

B83025D 

C83026A 

B83026B 

C83041A 

B85001L 

C86001F 

C94021A 

C97116A 

C98003B 

BA2011A 

CB7001A 

CB7001B 

CB7004A 

CC1223A 

BC1226A 

CC1226B 

BC3009B 

BD1B02B 

BD1B06A 

AD1B08A 

BD2A02A 

CD2A21E 

CD2A23E 

CD2A32A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

BD3006A 

BD4008A 

CD4022A 

CD4022D 

CD4024B 

CD4024C 

CD4024D 

CD4031A 

CD4051D 

CD5111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

AD7201A 

AD7201E 

CD7204B 

AD7206A 

BD8002A 

BD8004C 

CD9005A 

CD9005B 

CDA201E 

CE2107I 

CE2117A 

CE2117B 

CE2119B 

CE2205B 

CE2405A 

CE3111C 

CE3116A 

CE3118A 

CE3411B 

CE3412B 

CE3607B 

CE3607C 

CE3607D 

CE3812A 

CE3814A 

CE3902B 

2.2  INAPPLICABLE  TESTS 

A  test  is  inapplicable  if  it  contains  test  objectives  which  are  irrelevant 
for  a  given  Ada  implementation.  Reasons  for  a  test's  inapplicability  may  be 
supported  by  documents  issued  by  the  ISO  and  the  AJPO  known  as  Ada 
Commentaries  and  commonly  referenced  in  the  format  Al-ddddd.  For  this 
implementacion,  the  following  tests  were  determined  to  be  inapplicable  for 
the  reasons  indicated;  references  to  Ada  Commentaries  are  included  as 
appropriate. 
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The  following  201  tests  have  floating-point  type  declarations  requiring 
more  digits  than  SYSTEM. MAX_DIGITS : 


C24113L, .Y 
C35706L. .Y 
C35708L. .Y 
C45241L. .Y 
C45421L. .Y 
C45524L. .Z 
C45641L. .Y 


(14  tests) 
(14  tests) 
(14  tests) 
(14  tests) 
(14  tests) 
(15  tests) 
(14  tests) 


C35705L. .Y 
C35707L. .Y 
C35802L. .Z 
C45321L. .Y 
C45521L. .Z 
C45621L. .Z 
C46012L. .Z 


(14  tests) 
(14  tests) 
(15  tests) 
(14  tests) 
(15  tests) 
(15  tests) 
(15  tests) 


The  following  20  tests  check  for  the  predefined  type  LONG_lNTEGER;  for 
this  implementation,  there  is  no  such  type: 


C35404C 

G45502C 

C45613C 

C55B07A 


C45231C 

C45503C 

C45614C 

B55B09C 


C45304C 

C45504C 

C45631C 

B86001W 


C45411C 

C45504F 

C45632C 

C86006C 


C45412C 

C45611C 

B52004D 

CD7101F 


C35713B,  C45423B,  B86001T,  and  C86006H  check  for  the  predefined  type 

SHORT_FLOAT ;  for  this  implementation,  there  is  no  such  type. 


C35713D  and  B86001Z  check  for  a  predefined  floating-point  type  with  a 
name  other  .  than  FLOAT,  LONG_FLOAT,  or  SHORT_FLOAT;  for  this 
implementation,  there  is  no  such  type. 


C45531M. .P  and  C45532M..P  (8  tests)  check  fixed-point  operations  for 
types  that  require  a  SYSTEM. MAX_MANTISSA  of  47  or  greater;  for  this 
implementation,  MAX_MANTISSA  is  less  than  47 . 

C45624A. .B  (2  tests)  check  that  the  proper  exception  is  raised  if 
MACHINE_OVERFLOWS  is  FALSE  for  floating  point  types  and  the  results  of 
various  floating-point  operations  lie  outside  the  range  of  the  base 
type;  for  this  implementation,  MACHlNE_OVERFLOWS  is  TRUE. 


B86001Y  uses  the  name  of  a  predefined  fixed-point  type  other  than  type 
DURATION;  for  this  implementation,  there  is  no  such  type. 

C96005B  uses  values  of  type  DURATION'S  base  type  that  are  outside  the 
range  of  type  DURATION;  for  this  implementation,  the  ranges  are  the 
same. 

CD1009C  checks  whether  a  length  clause  can  specify  a  non-default  size 
for  a  floating-point  type;  this  implementation  does  not  support  such 
sizes . 


CD2A84A,  CD2A84E,  CD2A84I..J  (2  tests),  and  CD2A840  use  length  clauses 
to  specify  non-default  sizes  for  access  types;  this  implementation  does 
not  support  such  sizes. 
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The  tests  listed  in  the  following  table  check  that  USE_ERROR  is  raised 
if  the  given  file  operations  are  not  supported  for  the  given  combination 
of  mode  and  access  method;  this  implementation  supports  these 

operations. 

Test  File  Operation  Mode  File  Access  Method 


CE2102D 

CREATE 

CE2102E 

CREATE 

CE2102F 

CREATE 

CE2102I 

CREATE 

CE2102J 

CREATE 

CE2102N 

OPEN 

CE2102O 

RESET 

CE2102P 

OPEN 

CE2102Q 

RESET 

CE2102R 

OPEN 

CE2102S 

RESET 

CE2102T 

OPEN 

CE2102U 

RESET 

CE2102V 

OPEN 

CE2102W 

RESET 

CE3102E 

CREATE 

CE3102F 

RESET 

CE3102G 

DELETE 

CE3102I 

CREATE 

CE3102J 

OPEN 

CE3102K 

OPEN 

IN_FILE 

OUT_FILE 

INOUT_FILE 

IN_FILE 

OUT_FILE 

IN_FILE 

IN_FILE 

OUT_FILE 

OUT_FILE 

INOUT_FILE 

INOUT_FILE 

IN_FILE 

IN_FILE 

OUT_FILE 

OUT_FILE 

IN_FILE 

Any  Mode 


OUT_FILE 

IN_FILE 

OUT_FILE 


SEQUENTIAL_IO 

SEQUENTIAL_IO 

DIRECT_IO 

DIRECT_IO 

DIRECT_IO 

SEQUENTIAL_IO 

SEQUENTIAL_IO 

SEQUENTIAL_IO 

SEQUENTIAL_IO 

DIRECT_IO 

DIRECT_IO 

DIRECT_IO 

DIRECT_IO 

DIRECT_IO 

DIRECT_IO 

TEXT_IO 

TEXT_IO 

TEXT_IO 

TEXT_IO 

TEXT_IO 

TEXT_IO. 


CE2203A  checks  that  WRITE  raises  USE_ERROR  if  the  capacity  of  an 
external  sequential  file  is  exceeded;  this  implementation  cannot 
restrict  file  capacity. 


CE2403A  checks  that  WRITE  raises  USE_ERROR  if  the  capacity  of  an 
external  direct  file  is  exceeded;  this  implementation  cannot  restrict 

file  capacity. 

CE3115A  attempts  resetting  of  an  external  file  with  OUT_FILE  mode,  which 
is  not  supported  with  multiple  internal  files  associated  with  the  same 
external  file  when  they  have  different  modes. 

CE3304A  checks  that  SET_LINE_LENGTH  and  SET_PAGE_LENGTH  raise  USE_ERROR 
if  they  specify  an  inappropriate  value  for  the  external  file;  there  are 
no  inappropriate  values  for  this  implementation. 

CE3413B  checks  that  PAGE  raises  LAYOUT_ERROR  when  the  value  of  the  page 
number  exceeds  COUNT 'LAST;  for  this  implementation,  the  value  of 
COUNT ' LAST  is  greater  than  150000,  making  the  checking  of  this  objective 
impractical . 
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2.3  TEST  MODIFICATIONS 

Modifications  (see  section  1.3)  were  required  for  15  tests. 

The  following  tests  were  split  into  two  or  more  tests  because  this 
implementation  did  not  report  the  violations  of  the  Ada  Standard  in  the  way 
expected  by  the  original  tests. 

B24009A  B33301B  B38003A  B38003B  B38009A  B38009B 
B85005G  B85005H  B91001H  BC1313F  BC3005B  BD2B03A 
BD2D03A  BD4003A 

CE3804H  was  graded  passed  by  Evaluation  Modification  as  directed  by  the  AVO. 
This  test  requires  that  the  string  *-3.525"  can  be  read  from  a  file  using 
FL0AT_I0  and  that  an  equality  comparison  with  the  nrameric  literal  '-3.525' 
will  evaluate  to  TRUE;  however,  because  -3.525  is  not  a  model  niomber,  this 
comparison  may  evaluate  to  FALSE  (LRM  4.9:12).  This  implementation's 
compile-time  and  run-time  evaluation  algorithms  differ;  thus,  this  check  for 
equality  fails  and  Report .Failed  is  called  at  line  81,  which  outputs  the 
message  "WIDTH  CHARACTERS  NOT  READ. "  All  Other  checks  were  passed. 
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PROCESSING  INFORMATION 


3 . 1  TESTING  ENVIRONMENT 

The  Ada  implementation  tested  in  this  validation  effort  is  described 
adequately  by  the  information  given  in  the  initial  pages  of  this  report. 

For  technical  and  sales  information  about  this  Ada  implementation,  contact: 

Ed  Kelly 

Harris  Computer  Systems  Corporation 
2101  West  Cypress  Creek  Road 
Ft  Lauderdale  FL  33309-1892 
(305)  973-5340 

Testing  of  this  Ada  implementation  was  conducted  at  the  customer's  site  by  a 
validation  team  from  the  AVF. 


3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  Implementation  passes  a  given  ACVC  version  if  it  processes  each  test 
of  the  customized  test  suite  in  accordance  with  the  Ada  Programming  Language 
Standard,  whether  the  test  is  applicable  or  inapplicable;  otherwise,  the  Ada 
Implementation  fails  the  ACVC  [Pro95] . 

For  all  processed  tests  (inapplicable  and  applicable) ,  a  result  was  obtained 
that  conforms  to  the  Ada  Programming  Language  Standard. 

The  list  of  items  below  gives  the  number  of  ACVC  tests  in  various  categories. 
All  tests  were  processed,  except  those  that  were  withdrawn  because  of  test 
errors  (item  b;  see  section  2.1) ,  those  that  require  a  floating-point 
precision  that  exceeds  the  implementation's  maximum  precision  (item  e;  see 
section  2.2),  and  those  that  depend  on  the  support  of  a  file  system  --  if 
none  is  supported  (item  d) .  All  tests  passed,  except  those  that  are  listed 
in  sections  2.1  and  2.2  (counted  in  items  b  and  f,  below)  . 
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a)  Total  Number  of  Applicable  Tests 

b)  Total  Number  of  Withdravm  Tests 

c)  Processed  Inapplicable  Tests 

d)  Non-Processed  I/O  Tests 

e)  Non-Processed  Floating-Point 

Precision  Tests 


3795 

104 

70 

0 

201 


f)  Total  Number  of  inapplicable  Tests  271  (c+d+e) 

g)  Total  Number  of  Tests  for  ACVC  1.11  4170  (a+b+f) 


3.3  TEST  EXECUTION 

A  magnetic  tape  containing  the  customized  test  suite  (see  section  1.3)  was 
taken  on— site  by  the  validation  team  for  processing.  The  contents  of  the 
magnetic  tape  were  loaded  directly  onto  the  host  computer . 

After  the  test  files  were  loaded  onto  the  host  computer,  the  full  set  of 
tests  was  processed  by  the  Ada  implementation. 

The  tests  were  compiled,  linked  and  executed  on  the  host  computer  system. 
The  results  were  captured  on  the  host  computer  system. 

Testing  was  performed  using  command  scripts  provided  by  the  customer  and 
reviewed  by  the  validation  team.  See  Appendix  B  for  a  complete  listing  of 
the  processing  options  for  this  implementation.  It  also  indicates  the 
default  options.  The  following  options  were  used  for  testing  this 
implement  at i on : 

Compiler  option/switch  Effect 


[-el] 

[-i] 

[-W] 


(errors  list) 

(info) 

(warnings) 


Errors  &  source  to  stdout 
Suppress  information  only  messages 
Suppress  warning  and  info  messages 


Link  options 


Effect 


[-0  exec_file]  (output) 

[-w]  (warnings) 


Name  the  generated  program  "exec_file“ 
instead  of  the  default  name,  a. out. 
Suppress  warning  messages 


Test  output,  compiler  and  linker  listings,  and  job  logs  were  captured  on 
magnetic  tape  and  archived  at  the  AVF.  The  listings  examined  on-site  by  the 
validation  team  were  also  archived. 
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MACRO  PARAMETERS 


This  appendix  contains  the  macro  parameters  used  for  customizing  the  ACVC. 
The  meaning  and  purpose  of  these  parameters  are  ej^lained  in  [UG89] .  The 
parameter  values  are  presented  in  two  tables.  The  first  table  lists  the 
values  that  are  defined  in  terms  of  the  maximiam  input-line  length,  which  is 
the  value  for  $MAX_IN_LEN — also  listed  here.  These  values  are  expressed  here 
as  Ada  string  aggregates,  where  “V"  represents  the  maximum  input-line  length. 

Macro  Parameter  Macro  Value 


$MAX_IN_LEN 

499 

—  Value  of  V 

$BIG_ID1 

(1. 

< 

1 

II 

V 

> 

< 

ii 

V 

$BIG_ID2 

(1. 

.V-1  =>  'A' ,  V  =>  '2') 

$BIG_ID3 

(1. 

.V/2  =>  'A')  &  '3'  & 

(1. .V-l-V/2  =>  'A' ) 

$BIG_ID4 

(1. 

.V/2  =>  'A')  &  '4'  & 

(1. .V-l-V/2  =>  'A' ) 

$BIG_INT_LIT 

(1. 

.V-3  =>  '0')  &  “298" 

$BIG_REAL_LIT 

(1. 

.V-5  =>  '0')  &  “690.0" 

$BIG_STRING1 

/  M  / 

&  (1. .V/2  =>  'A' )  &  ' ” ' 

$BIG_STRING2 

r  H  / 

&  (1.. V-l-V/2  =>  'A')  &  '1' 

$ BLANKS 

(1. 

A 

II 

O 

CM 

> 

$MAX_LEN_INT_BASED. 

LITERAL 

“2: "  &  (1. .V-5  =>  '0' )  &  "11: " 

$MAX_LEN_REAL_BASED_LITERAL 

“16:“  &  (1. .V-7  =>  '0')  &  "F.E:" 
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$MAX_STRING_LITERAL  &  (1..V-2  =>  'A')  & 

The  following  table  lists  all  of  the  other  macro  parameters  and  their 
respective  values. 

Macro  Parameter  Macro  Value 

$ACC_SIZE  32 

$ALIGNMENT  8 

$COUNT_LAST  2147483647 

$DEFAULT_MEM_SIZE  3221225469 

$DEFAULT_STOR_UNIT  8 
$DEFAULT_SYS_NAME  KARRI S_POWER 

$DELTA_DOC  2.0** (-31) 

$ENTRY_AD DRESS  SYSTEM , PHYSICAL_ADDRESS ( 16 ) 

$ENTRY_ADDRESS1  SYSTEM . PHYSICAL_ADDRESS  ( 17 ) 

$ENTRY_ADDRESS2  SYSTEM. PHYSICAL_ADDRESS (18 ) 

$FIELD_LAST  2147483647 

$FILE_TERMINATOR  '  ' 

$FIXED_NAME  NO_SUCH_FIXED_TYPE 

$FLOAT_NAME  NO_SUCH_FLOAT_TYPE 

$FORM_STRING 

$FORM_STRING2  “ CANNOT_RESTRICT_FILE_CAPACITY " 

$  GREATER_THAN_DURAT I ON 

100000.0 

$  GREATER_THAN_DURAT I ON_BASE_L AST 

10000000.0 

$GREATER_THAN_FLOAT_BASE_LAST 

3.5E+38 

$GREATER_THAN_FLOAT_SAFE_LARGE 

l.OE+38 
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$GREATER_THAN_SHORT_FLOAT_SAFE_LARGE 

l.OE+308 

$HIGH_PRIORITY  255 

$ ILLEGAL_EXTERNAL_FILE_NAME1 

/no/ such/ file/name 

$ILLEGAL_EXTERNAL_FILE_NAME2 

/this/ file/does/not /exist 

$ INAPPROPRI ATE_L INE_LENGTH 

-1 


$ INAPPROPRI ATE_PAGE_LENGTH 

-1 


$  INCIiUDE_PRAGMAl 

$  INC  LUDE_PRAGMA2 

$INTEGER_FIRST 

$INTEGER_LAST 

$INTEGER_LAST_PLUS_1  2147483648 

$INTERFACE_LANGUAGE  C 

$LESS_THAN_DURATION  -100000.0 

$LESS_THAN_DURATION_BASE_FIRST 

-10000000.0 


PRAGMA  INCLUDE  ( "A28006D1 . TST‘ ) 
PRAGMA  INCLUDE  ( “B2 8006D1 . TST" ) 
-2147483648 
2147483647 


$LINE_TERMINATOR 

$LOW_PRIORITY 


ASCII. LF 
0 


$  MACH INE_CO DE_S T ATEMENT 

code_3 ' ( or_r , r 0 , r 0 , rO ) 


$MACHINE_CODE_TYPE 

$MANTISSA_DOC 

$MAX_DIGITS 

$MAX_INT 

$MAX_INT_PLUS_1 

$MIN_INT 

$NAME 


operand 

31 

15 

2147483647 

2_147_483_648 

-2147483648 

TINY_INTEGER 

A-3 


MACRO  PARAMETERS 


$NAME_LIST 

KARRI S_POWER 

$NAME_SPECIFICATIONl 

/jas2/AT/VAL/ppc604//tests/ce/CE2120A 

$NAME_SPECIFICATION2 

/ jas2/AT/VAL/ppc604//tests/ce/CE2120B 

$NAME_SPECIFICATION3 

/jas2/AT/VAL/ppc604//tests/ce/CE3119A 

$NEG_BASED_INT 

16#FOOOOOOE# 

$NEW_MEM_SIZE 

3221225469 

$NEW_STOR_UNIT 

8 

$NEW_SYS_NAME 

KARRI S_POWER 

$  PAGE_TERMINATOR 

ASCII. LF  &  ASCII. FF 

$RECORD_DEFINITION 

type  code_l  (op:  opcode)  is 

record  oprnd_l :  operand  ;  end  record 

$RECORD_NAME 

code_l 

$TASK_SIZE 

32 

$ TASK_STORAGE_S I ZE 

10240 

$TICK 

0.01 

$ VARI ABLE_ADDRE S S 

FCNDECL . SPACE (1024 ) 

$VARIABLE_ADDRESS1 

FCNDECL . SPACE ( 1024 ) 

$VARIABLE_ADDRESS2 

FCNDECL . SPACE (1024) 

$YOUR_PRAGMA 

EXTERNAL_NAME 

APPENDIX  B 

COMPILATION  SYSTEM  OPTIC»IS 


The  compiler  options  of  this  Ada  inplementation,  as  described  in  this 
Appendix,  are  provided  by  the  customer.  Unless  specifically  noted  otherwise, 
references  in  this  appendix  are  to  coitpiler  documentation  and  not  to  this 
report. 
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LINKER  OPTIONS 

The  linker  options  of  this  Ada  implementation,  as  described  in  this  Appendix, 
are  provided  by  the  customer.  Unless  specifically  noted  otherwise, 
references  in  this  appendix  are  to  linker  documentation  and  not  to  this 
report. 
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APPENDIX  F  OF  THE  Ada  STANDARD 


The  only  allowed  implementation  dependencies  correspond  to 
implementation-dependent  pragmas,  to  certain  machine-dependent  conventions  as 
mentioned  in  Chapter  13  of  the  Ada  Standard,  and  to  certain  allowed 
restrictions  on  representation  clauses.  The  implementation-dependent 
characteristics  of  this  Ada  implementation,  as  described  in  this  Appendix, 
are  provided  by  the  customer.  Unless  specifically  noted  otherwise, 
references  in  this  Appendix  are  to  compiler  documentation  and  not  to  this 
report.  implementation-specific  portions  of  the  package  STANDARD,  which  are 
not  a  part  of  Appendix  F,  are: 


package  STANDARD  is 


type  INTEGER  is  range  -2_147_483_648  ..  2_147_483_647 ; 
type  SHORT_INTEGER  is  range  -32_768  ..  32_767; 
type  TINY_INTEGER  is  range  -128  ..127; 

type  FLOAT  is  digits  6  range  -1.70141E+38  ..  1 . 70141E+38 ; 
type  LONG_FLOAT  is  digits  15  range  -1 . 79769313486232E+308 

..  1.79769313486232E+308; 

type  DURATION  is  delta  2.0** (-14)  range  -131_072.0  ..  131_072.0; 


end  STANDARD; 
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Table  5-1.  ada  Options 


Option 

Meaning 

Function 

-a  name 

(ada  source) 

Save  preproccssed  source  file  in  name. 

-b 

(object) 

Symbolic  object  listing  to  stdout 

-boimd 

(bound) 

Pass  -bound  to  a-ld.  The  -M  option  must  also  be  specified. 

“C 

(compress) 

Compress  executable  program  by  removing  “dead”  routines.  The  -M 
option  must  also  be  specified. 

-d 

(dependencies) 

Analyze  for  dependencies  but  do  not  compile. 

-e 

(error) 

Process  syntax  error  messages  using  a .  error  and  direct  the  output  to 
stdout,  (i.e.,  list  only  the  errors). 

-el 

(error  listing) 

Generate  an  error  listing  using  a .  error  and  direct  it  to  stdout,  i.e., 
list  the  entire  source  file. 

-ev 

(error  vi) 

Process  syntax  error  message  using  a. error,  embed  them  in  the 
source  file,  and  call  vi. 

-glleve[\ 

(debug  level) 

Specify  the  debug  level.  The  level  may  be  n  (none),  0  (lines)  or  1 
(full).  (Default  is  -gO). 

-hapse  HAPSE 

(hapse) 

Select  a  HAPSE  installation. 

-i 

(info) 

Suppress  informational  messages. 

-Id  file 

(loader) 

Pass  file  to  Id.  The  -M  option  must  also  be  specified. 

-lib  library 

(library) 

Select  a  HAPSE  library. 

-m 

(map) 

Display  an  object  map.  The  -M  option  must  also  be  specified. 

-multiplexed 

(multiplexed) 

Pass  -multiplexed  to  a.ld.  The  -M  option  must  also  be  specified. 

-ns hare  item 

(no  sharelib) 

Pass  “-nshare  item**  to  a  •  Id.  The  -M  option  must  also  be  specified. 
See  a .  Id. 

-nshare_all 

(nshare) 

Pass  “-nshare_all”  to  a.ld.  The  -M  option  must  also  be  speci¬ 
fied.  See  a.ld. 

-o  output 

(output) 

After  compilation,  call  a .  Id.  Rename  the  executable  program  to  the 
specified  name.  The  -M  option  must  also  be  specified. 

-pp  options 

(preprocess) 

Pass  options  to  a .  pp. 

-q 

(quick) 

Do  not  invoke  code  generator;  check  syntax  and  semantics  and  update 
ada .  lib. 

-s  file 

(source) 

Compile where is  an  Ada  source  file  not  ending  in  .a,  .  ada, 
or  .pp. 

-share  item 

(sharelib) 

Pass  “-share  item**  to  a .  Id.  The  -M  option  must  also  be  specified. 
See  a .  Id. 

-share_all 

(share) 

Pass  “-  share_all”  to  a .  Id.  The  -M  option  must  also  be  specified. 
See  a .  Id. 

-sm  mode 

(share  mode) 

Set  the  sharing  compilation  mode  to  shared,  non_shared,  or 
both.  (Default  -s  -sm  non^shared). 
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Table  5>1.  ada  Options  (Cent.) 


Option 

Meaning 

Function 

-u 

(update) 

Update  the  library  ada .  lib  even  if  syntax  errors  are  present 

-V 

(verbose) 

Display  information  about  the  compilation. 

-w 

(warnings) 

Suppress  warning  and  informational  diagnostics. 

-E 

-E  file 
-E  directory 

(error  output) 

Process  error  messages  using  a .  error  and  direct  the  output  to  std- 
out  as  well  as  (-E)  ada_source.err,  file)  file,  or  (-E  directory) 

directorylada_source.err. 

-El 

-El  file 
-El  directory 

(error  listing) 

Process  source  listing  with  errors  using  a. error  as  well  as  (-E1) 
ada_source.err,  (-El  file)  file,  or  (-E1  directory)  direc¬ 
tory!  ada_source.err. 

-H 

(help) 

Display  this  description  and  stop. 

-K 

(keep) 

Keep  the  IL  file  created  by  the  front  end. 

-L 

(list) 

Generate  a  source  listing  to  stdout,  even  if  there  are  no  errors. 

-M  urdtjuxme 
-M  odajsourceM 

(main) 

After  compilation,  call  a .  Id  to  produce  an  executable  program  with 
the  named  main  program  or  source  root  name. 

-N 

(No  sharing) 

Apply  pragma  SHARE_B0DY  (FALSE)  to  all  generics  (see  “Pragma 
SHARE_BODY”  on  page  9-15.). 

-0[/-5] 

(optimize) 

Apply  pragma  OPT_LEVEL  to  the  compilation.  (See  “Pragma 
OPT^LEVEL”  on  page  9-10.)  If  a  number  is  qq!  specified,  then  level 

2  is  assumed.  Levels  1-3  correspond  to  MINIMAL,  GLOBAL,  and 
MAXIMAL,  respectively,  as  described  in  “Optimizations  Performed  at 
the  Various  Levels”  on  page  10-3.  (Default  is  -01). 

-P 

(preprocess) 

Invoke  a  .pp  before  compiling  source  files. 

-Qflags 

(qualifier) 

Supply  qualifier  flags  to  the  compiler  (see  “Back-End  Qualifier  (-Q) 
Flags”  on  page  5-8). 

-R  library 

(recompile) 

Force  updating  of  instantiations. 

-S 

(suppress) 

Apply  pragma  SUPPRESS_ALL 

-T 

(timings) 

Display  the  wall  and  CPU  times  used  by  the  compiler. 

-V 

(very  verbose) 

Display  verbose  compilation  information. 
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Table  5-7.  a.ld  Options 


Option 

Meaning 

Function 

-bound 

(bound) 

Set  the  default  task  weight  to  BOUND. 

-c(vtV] 

(compress) 

Compress  executable  image  by  removing  “dead”  routines. 

-d 

(default) 

Use  default  supplied  libraries.  For  use  with  the  -share 
and  -nshare  options. 

-hapse  HAPSE 

(HAPSE) 

Select  a  HAPSE  installation. 

-i  elab_sym 

(initialize) 

Insert  the  elaboration  routine  specified  by  elabjym  at  the 
elaboration  list  bead. 

-lib  library 

(library) 

Select  a  HAPSE  library. 

-m 

(mrq)) 

Produce  a  link  map  and  direct  it  to  stdout 

-map  file 

(map) 

Produce  a  run-time  configuration  map  file  (“file”)  for  this 
program. 

-multiplexed 

(multiplexed) 

Set  the  default  task  weight  to  MULTIPLEXED.  (This  is  the 
default). 

-n 

(no  datarec) 

Do  not  produce  a  data  recording  file. 

-nshare  item 

(no  sharelib) 

Do  not  allow  units  from  HAPSE  library  item  to  come  from 
shared-objects.  See  -d^  -share_all,  -share, 
-nshare_all. 

-nshare_all 

(nshare) 

Disable  the  use  of  any  shared-objects,  forcing  static  linking. 
See  - share_all ,  -nshare,  -share. 

-ntrace 

(NightTrace) 

Use  an  ntrace  run-time  which  requires  the  NightTrace 
daemon,  ntraceud,  for  execution.  This  option  cannot  be 
combined  with  -  trace. 

-o  executable Jile 

(output) 

Use  executable  Jile  as  the  name  of  the  output  rather  than  the 
default,  a .  out. 

-share  item 

(sharelib) 

Force  units  from  HAPSE  library  item  to  come  from  a 
shared-object.  See  -d,  -share_all,  -nshare, 
-nshare_all. 

-share_all 

(share) 

Enable  the  use  of  HAPSE  shared-objects  as  well  as  system 
shared  libraries.  See  -nshare,  -nshare_all, 
-share. 

-shmem  yarams'’ 

(shared  memory) 

Supplies  a  quoted  string  containing  shared  package  configu¬ 
ration  parameters.  Consult  ?Section  6.2.2  for  a  description 
of  these  parameters. 

-trace 

(trace) 

Link  with  a  tracing  version  of  the  run-time.  This  option  can¬ 
not  be  combined  with  -ntrace. 

-update 

(update) 

Update  shared-object  for  the  selected  HAPSE  library.  No 
link  of  an  application  program  will  be  performed. 

-V 

(verbose) 

Display  the  linker  commands  before  execution. 

-w 

(warnings) 

Suppress  warning  diagnostics. 
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Table  5-7.  a.id  Options  (Cent) 


Option 

Meaning 

Function 

-A  *'args*' 

(analyze) 

Invoke  a. analyze  with  a  list  of  arguments  placed  within 
quotation  marks. 

-P 

(files) 

Display  a  list  of  required  files,  suppressing  linking. 

-H 

(help) 

Display  this  description  and  stop. 

-  0  [executable Jile] 

(optimize) 

Perform  optimizations  at  link  time  by  invoking  the  a .  ana- 
lyze  optimizer.  If  executable  Jile  is  specified,  it  overrides 
any  name  specified  by  the  -o  option,  or  a .  out  if  no  -o 
option  is  specified.  (-0  is  not  used  by  default). 

-u 

(units) 

Display  a  list  of  required  units  in  elaboration  order,  sup¬ 
pressing  linking. 

-V 

(verify) 

Display  the  linker  commands,  but  suppress  execution. 
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Implementation-Dependent  Characteristics 


NOTE 

This  chapter  serves  as  Appendix  F  of  the  Ada  RM. 


Program  Structure  and  Compilation 


A  “main”  program  must  be  a  non-generic  subprogram  without  parameters  that  is  either  a 
procedure  or  a  function  returning  an  Ada  STANDARD .  INTEGER  (the  predefined  type).  A 
“main”  program  cannot  be  a  generic  subprogram  or  an  instantiation  of  a  generic  subpro¬ 
gram. 


Pragmas 


The  following  text  discusses  implementation-dependent  and  implementation-defined 
pragmas.  A  pragma  syntax  summary  appears  in  the  HAPSE  Pocket  Reference. 


Pragma  BUILTJN 


NOTE 

Pragma  built_IN  is  for  internal  HAPSE  use  only;  it  is  not 
applicable  to  user-defined  subprograms. 


The  implementation-defined  pragma  BUILT_IN  specifies  that  a  subprogram  is  defined  to 
be  an  impUcit  operation  intrinsic  to  the  compiler  and  that  it,  therefore,  does  not  require  an 
explicit  subprogram  body.  The  syntax  of  the  pragma  is  as  follows: 

pragma  BUILT_IN  (subprogramjutme) ; 

All  calls  to  the  specified  subprogram  are  replaced  with  code  sequences  that  perform  the 
operations  that  are  implicitly  defined  for  the  subprogram,  if  any  such  code  sequences  are 
required. 
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Pragma  CONTROLLED 


The  implementation-dependent  pragma  controlled  is  recognized  by  the  implementa¬ 
tion  but  does  not  have  an  effect  in  this  release. 


Pragma  DEBUG 


The  implementation-defined  pragma  DEBUG  provides  a  method  for  specifying  the  debug 
level  for  a  compilation  unit  from  within  the  Ada  source  code.  The  format  of  the  pragma 
is: 


pragma  DEBUG  {umtjiame,  debug Jevel) ) 

V, 

where  unit  name  is  the  name  of  the  compilation  unit  for  which  the  debug  level  is  being 
specified,  and  where  debug^level  is  the  debug  level  which  should  be  used  for  that  compi¬ 
lation  unit.  The  possible  values  for  debug Jlevel  are  NONE,  LINES,  and  FULL.  This 
pragma  is  allowed  only  immediately  following  the  unit  which  is  specified  as  the 
unit  name  argument  It  ^>plies  only  to  the  unit  which  is  specified.  If  applied  to  a  specifi¬ 
cation,  the  debug  level  does  not  apply  to  the  body  or  any  separate  bodies  of  the  umt.  If 
applied  to  a  body,  the  debug  level  does  ngt  apply  to  any  separate  bodies  of  the  umt.  If  the 
debug  level  is  desired  for  any  such  units,  it  must  be  specified  for  them  too. 

The  pragma  is  meaningless  when  applied  to  a  generic  unit.  If  so  applied,  it  will  not  be 
applied  to  any  instantiations  of  that  generic.  The  debug  level  applied  to  an  instantiation  is 
the  debug  level  of  the  unit  which  contains  it,  or,  if  the  instantiation  is  library-level,  is 
determined  in  the  same  way  as  for  any  other  library-level  unit 


Pragma  DEFAULT_HARDNESS 


The  implementation-defined  pragma  DEFAULT_HARDNESS  sets  the  default  hardness  for 
any  memory  bound  to  LOCAL  via  a  pragma  MEMORY_POOL.  See  “Pragma 
DEFAULT_HARDNESS”  on  page  20-2  for  a  complete  description. 


Pragma  DEPRECATED_FEATURE 


NOTE 

Pragma  DEPRECATED_FEATURE  is  reserved  for  internal  HAPSE 
use  only;  it  is  not  intended  for  use  in  user-defined  code. 


This  pragma  is  used  to  mark  packages  that  have  been  deprecated  and  may  be  significantly 
changed  or  completely  removed  in  future  releases  of  HAPSE.  Whenever  a  compilation 
unit  requires  a  unit  (e.g.,  via  a  with  clause)  that  has  been  marked  with  this  pragma,  a 
compiler  alert  (diagnostic)  is  issued.  The  alert  consists  of  a  standard  HAPSE  diagnostic 
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header  followed  by  the  exact  text  of  the  string  that  is  the  single  required  argument  of  the 
pragma. 


Pragma  ELABORATE 

The  implementation-dependent  pragma  ELABORATE  is  implemented  as  described  in 
Appendix  B  of  the  Ada  RM. 


Pragma  EXTERNAL_NAME 

The  implementation-defined  pragma  EXTERNAL_NAME  provides  a  method  for  specifying 
an  alternative  link  name  for  variables,  functions  and  procedures,  pie  required  parameters 
are  the  simple  name  of  the  object  and  a  string  constant  representing  the  link  name.  Link 
names  are  case-sensitive.  Note  that  this  pragma  is  useful  for  referencing  functions  and 
procedures  that  have  had  pragma  INTERFACE  applied  to  them,  in  such  cases  where  fee 
functions  or  procedures  have  link  names  feat  do  not  conform  to  Ada  identifiers.  The 
pragma  must  occur  after  any  such  applications  of  pragma  INTERFACE  and  within  the 
same  declarative  part  or  package  specification  that  contains  the  object.  The  compiler 
automatically  removes  the  first  leading  underscore. 

Example: 

Use  the  external_name  pragma  to  make  an  Ada  routine  visible  externally.  The  link 
name  may  then  be  referenced  by  other  programs  to  call  the  Ada  routine.  Some  sample 
Ada  code  follows: 

package  stuff  is 

function  calljie  return  integer; 

pragma  EXTERNAL_NAME  (call^me,  "Ada_call"); 

end  stuff; 

package  body  stuff  is 

function  call_me  return  integer  is 
begin 

return  0; 
end  call_me; 

end  stuff; 

The  routine  call_me  is  now  visible  under  the  link  name  “Ada_call”.  Other  subpro¬ 
grams  can  now  call  this  function  by  referring  to  the  external  name  given  to  the  routine. 
For  example,  an  Ada  subprogram  can  call  the  function  as  follows: 

procedure  excunple  is 

Ada_value  :  integer; 

function  Ada_call  return  integer; 
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pragma  interface (  Ada,  Ada_call  ) ; 
begin 

Ada_value  : =  Ada_call ; 
end  excunple; 

In  general,  calling  Ada  subprograms  in  this  manner  should  be  avoided  because  of  the 
complexities  of: 

•  Elaboration  order 

•  Up-level  referencing 

•  Hidden  compiler-generated  parameters  (generics,  unconstrained  arrays  and 
records) 

•  Run-time  elaboration  (tasking,  exception) 


Pragma  FAST_1NTERRUPT_TASK 


The  implementation-defined  pragma  FAST_INTERRUPT_TASK  provides  ultra-fast  inter¬ 
rupt  handling.  Use  of  this  pragma  causes  the  task  to  execute  directly  at  interrupt-level. 
Use  of  this  pragma  requires  severe  limitations  on  the  form  of  the  task  and  the  actions  taken 
during  rendezvous. 

The  compiler  enforces  many  of  the  restrictions  on  the  task;  however,  others  carmot  be 
detected  and  are  not  enforced  by  the  compiler.  For  details,  see  “Pragma 
FAST^INTERRUPT_TASK”  on  page  21-4. 


Pragma  GROUP_CPU_BIAS 


The  implementation-defined  pragma  group_CPU_bias  specifies  the  CPU  bias  for  all 
the  servers  in  a  given  group.  See  “Pragma  GROUP_CPU_BIAS”  on  page  20-10  for  a 
complete  description. 


Pragma  GROUP.PRIORITY 


The  implementation-defined  pragma  GROUP_PRIORITY  specifies  the  operating  system 
priority  of  all  the  servers  in  a  given  group.  See  “Pragma  GROUP_PRIORITY”  on  page 
20-10  for  a  complete  description. 


Pragma  GROUP_SERVERS 


The  implementation-defined  pragma  gR0UP_SERVERS  controls  the  number  of  servers 
for  a  particular  group,  including  the  PREDEFINED  group.  See  “Pragma 
GROUP_SERVERS”  on  page  20-11  for  a  complete  description. 
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Pragma  IMPLICIT_CODE 

The  implementadon-defined  pragma  IMPLICIT^CODE  provides  a  way  to  eliminate  the 
stack  frame  and  the  copying  of  parameters  when  using  the  itiachine_code  package. 
This  pragma  takes  a  single  argument  (ON  or  OFF).  When  OFF,  it  does  not  generate  code 
for  the  argument  copies,  nor  does  it  generate  any  return  code  upon  exiting.  It  can  be  used 
as  an  optimization  for  writing  machine^code  routines  to  eliminate  the  generation  of  the 
implicit  code.  An  example  demonstrating  the  use  of  this  pragma  is  given  in  Usage  on 
page  9-36. 


Pragma  INLINE 


The  implementation-dependent  pragma  INLINE  is  implemented  as  described  in  Section 
6.3.2  and  Appendix  B  of  the  Ada  RM,  however,  there  are  a  number  of  restrictions  on 
inline  subprogram  expansion.  The  compiler  will  issue  a  warning,  not  perform  the  inline 
expansion,  and  output  code  for  a  subprogram  call,  if  any  of  these  restrictions  are  violated 
or  exceeded. 

The  restrictions  and  limitations  on  inline  subprogram  expansion  include: 

•  The  body  of  the  subprogram  must  be  compiled  before  it  can  be  expanded 
inline.  The  HAPSE  reconqjilation  utility,  a .  make,  will  attempt  to  compile 
bodies  that  define  inline  subprograms  before  bodies  that  use  inline  subpro¬ 
grams,  however,  if  two  bodies  contain  mutual  inline  dependencies  a  •  make 
will  choose,  in  an  arbitrary  manner,  which  to  compile  first  (See  “Inline 
Dependencies  and  a.make”  on  page  5-39.) 

•  There  are  a  number  of  Ada  constructs  that  will  prevent  inline  expansion  if 

they  appear  in  the  declarations  of  a  subprogram  marked  with  pragma 
INLINE.  These  constructs  include  tasks,  most  generic  instantiations,  and 
(inner)  subprograms  that  perform  up-level  addressing. 

•  Direct  or  indirect  recursive  calls  are  never  inline  expanded. 

•  The  actual  parameters  to  the  inline  expanded  subprogram  must  not  contain 
fask  objects,  must  not  contain  dependent  arrays,  and  must  have  complete 
type  declarations. 

•  Subprograms  marked  with  pragma  INTERFACE  are  never  inline  expanded. 

The  uncontrolled  use  of  inline  expansion  can  adversely  affect  the  performance  of  the 
HAPSE  compiler  itself.  Inline  expansion  can  be  controlled  by  using  HAPSE  configura¬ 
tion  management  described  in  “Inline  Parameters’*  on  page  12-4. 

Subprograms  that  contain  machine-code  insertion  statements  are  always  inline  expanded 
if  they  are  mariced  with  pragma  INLINE,  regardless  of  any  configuration  limits. 
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WARNING 

It  is  not  recommended  practice  to  inline  machine-code  proce¬ 
dures,  as  the  compiler  does  not  track  register  uses  and  definitions 
made  by  machine-code  procedures.  Inlining  of  machine-code 
procedures  is  supported,  but  die  user  should  exercise  caution. 


Pragma  INTERFACE 

The  implementation-depencient  pragma  INTERFACE  is  recognized  by  the  implementation 
and  supports  calls  to  C,  Fortran,  Ada  and  other  language  functions.  The  Ada  specifica¬ 
tions  can  be  either  functions  or  procedures.  For  C  and  Fortran,  all  parameters  must  have 
mode  IN.  See  Chapter  1 1  of  this  manual  for  examples. 

For  C,  the  types  of  parameters  as  well  as  the  result  type  for  functions  must  be  scalar, 
access,  or  the  predefined  type  SYSTEM.  ADDRESS.  Record  and  array  objects  can  be 
passed  by  reference  using  the  ADDRESS  attribute.  Users  must  ensure  that  representation 
"  of  records  and  arrays  are  in  the  form  expected  by  the  called  subprogram.  The  default  link 

name  is  the  symbolic  representation  of  the  simple  name  converted  to  lower  case.  For  more 
information  about  C,  see  the  Harris  C  Reference  Manual 

For  Fortran,  all  parameters  are  passed  by  reference.  The  parameter  types  must  have  the 
type  ADDRESS  defined  in  the  package  SYSTEM.  The  user  is  responsible  for  passing  the 
arguments  by  reference,  typically  by  using  the  ADDRESS  attribute.  For  example: 

c  add  (a' address,b' address) ; 

The  result  type  for  a  Fortran  function  must  be  a  scalar  type.  Care  should  be  taken  when 
using  tasking  and  Fortran  functions.  Since  Fortran  is  not  reentrant,  it  is  recommended  that 
an  Ada  controller  task  be  used  to  control  concurrent  access  to  Fortran  functions.  The 
default  link  name  is  the  symbolic  representation  of  the  simple  name  converted  to  lower 
case  with  a  trailing  underscore  (_)  character.  For  more  information  about  Fortran,  see  the 
Hf77  Fortran  Reference  Manual 

For  Ada,  the  types  and  modes  of  parameters  are  unrestricted.  The  default  link  name  is  the 
symbolic  representation  of  the  simple  name  converted  to  lower  case. 

For  other  languages  UNCHECKED,  which  allows  all  parameter  types  and  modes,  should  be 
specified.  The  user  must  ensure  that  the  called  subprograms  conform  to  the  standard  call¬ 
ing  sequence  for  scalar  and  address  data  types.  The  user  is  responsible  for  forming  alter¬ 
native  calling  sequences  when  passing  non-scalar  or  non-address  arguments  (e.g.,  passing 
a  character  string,  etc.).  The  default  link  name  is  the  symbolic  representation  of  the  sim¬ 
ple  name  converted  to  lower  case. 

The  link  name  of  interface  routines  can  be  changed  via  the  implementation-defined 
pragma  external^name. 

Care  should  be  taken  when  using  Ada  tasking  and  interfacing  to  subprograms  written  in 
non-reentrant  languages,  such  as  Fortran.  In  such  cases,  an  Ada  controller  task  may  be 
used  to  manage  concurrent  access  to  such  routines. 
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Pragma  INTERFACE_N  AME 

The  implementation-defined  pragma  INTERFACE_NAME  provides  a  method  for  specify¬ 
ing  external  names  te  variables,  functions,  and  procedures.  The  required  parameters  arc 
the  simplft  namft  of  the  object  and  a  string  constant  repte»nting  &e  external  name.  The 
pragma  may  not  be  ^>plied  to  objects  diat  have  been  explicitly  initialized.  For  all  practi- 
cal  purposes,  this  pragma  is  equivalent  to  the  EXTERNAL_NAME  pragma. 


Pragma  INTERFACE_OBJECT 

The  implementation-defined  pragma  INTERFACE_0B  JECT  provides  ^  interface  to 
objects  defined  externally  from  the  Ada  compilation  model,  or  an  object  defined  in 
another  language.  For  example,  a  variable  defined  in  the  run-time  system  may  be  accessed 
via  the  pragma.  This  pragma  has  two  required  parameters,  the  first  being  the  simple  name 
of  an  Ada  variable  to  be  associated  with  the  foreign  object  The  second  paraineter  is  a 
string  constant  that  defines  the  link  name  of  the  object.  The  variable  declaration  must 
occur  before  the  pragma  and  both  must  occur  within  the  same  declarative  part  or  package 
specification. 

An  example  is  the  C-language  variable  errno  in  the  following  code, 
declare 

errno  :  integer  ; 

pragma  inter face^object  (  errno,  ^ errno"  )  ; 
begin 

end  ; 


Pragma  INTERFACE_SHARED_OBJECT 

The  implftniftTitafion -defined  pragma  lNTERFACE_SHARED_OBJECT  provides  an  inter¬ 
face  to  objects  defined  in  odier  languages  which  exist  in  shared  memory  segments.  Spe¬ 
cifically,  this  allows  for  the  sharing  of  data  between  Ada  objects  and  Fortran  or  C  objects 
defined  within  the  same  process  or  in  a  separate  process. 

Pragma  interface_SHARED_OBJECT  associates  an  Ada  variable  with  a  shared  mem¬ 
ory  segment  It  has  two  required  parameters.  The  first  parameter  is  the  simple  name  of 
the  Ada  variable  to  be  associated  with  the  foreign  object  The  second  parameter  is  a  string 
constant  that  defines  the  external  link  name  of  the  object  as  defined  in  the  other  language. 
The  variable  declaration  must  occur  before  the  pragma  and  both  must  occur  within  the 
same  declarative  part  or  package  specification. 

Variables  marked  with  the  pragma  must  have  a  static  size.  It  is  recommended  that  an 
explicit  length  clause  be  specified  for  composite  objects  to  ensure  conformance  with  the 
size  as  defined  by  the  other  language.  Additionally,  record  representation  clauses  may  be 
used  to  define  the  layout  of  records  to  match  the  other  language  defimtions. 

The  association  of  the  shared  memory  segment  to  the  Ada  variable  is  effected  at  program 
start-up  time,  by  the  HAPSE  run-time  system.  However,  specific  control  over  the  config- 
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uration  of  the  shared  memory  is  defined  externally  from  die  Ada  compilation  model  and 
requires  user  intervention.  The  Power  UNIX  shmdefixie  utility  has  been  provided  to  aid 
the  user  in  defining  the  configuration  of  shared  memory  segments.  The  utility  produces  a 
link-ready  file  and  a  loader  command  file  which  must  be  included  in  the  link  of  any  Ada 
program  using  pragma  lNTERFACE_SHARED_OB  JECT.  To  include  these  files  in  the 
link  process,  the  user  should  invoke  the  HAPSE  prelmkcr,  a  •  Id,  adding  the  names  of 
these  files  to  the  end  of  the  command  line.  See  Chapter  1 1  of  this  manual  for  an  example 
application  of  the  pragma.  See  also  shmdef  Ine  ( 1 ) . 


Pragma  LINK_OPTION 


The  implementation-defined  pragma  LINK_OPTION  allows  a  command  to  the  linker 
Id  ( 1 )  to  be  specified  in  an  Ada  compilation  umt  The  pragma  has  one  required  parame¬ 
ter,  a  string  within  quotes  containing  the  command  to  be  passed  to  Id.  The  string  specified 
will  be  passed  directly  to  Id  by  the  a  •  Id  tool.  For  example,  if  a  compilation  umt  refer¬ 
ences  the  system  curses  library,  the  pragma: 

pragma  LINK_OPTION(  ^ -Icurses'' )  ; 

can  be  used  in  the  compilation  unit  to  link  the  curses  library  with  the  resulting  Ada  pro¬ 
gram.  An  example  usage  of  this  pragma  may  be  found  in  the  HAPSE  harrislib 
library’s  MATH  package.  The  body  of  this  package  contains  a  LINK_OPTlON  pragma  that 
causes  all  programs  that  specify  the  package  MATH  in  a  with  clause  to  be  automatically 
linked  with  the  system  math  library. 


Pragma  LIST 


The  implementation-dependent  pragma  LIST  is  implemented  as  described  in  Appendix  B 
of  the  Ada  RM. 


Pragma  MAP_FILE 


The  implementation-defined  pragma  MAP_FILE  causes  a  •  Id  to  automatically  emit  a 
map  file  at  link  time.  See  “Pragma  MAP_FILE”  on  page  20-1  for  a  complete  description. 


Pragma  MEMORY_POOL 

The  implementation-defined  pragma  memory_pool  is  used  to  change  physical  meniory 
pool  attributes  from  their  default  values  for  a  memory  pool.  See  “Memory  Attributes”  on 
page  20-1 1  and  “Pragma  MEMORY_POOL”  on  page  20-13  for  a  complete  description. 
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Pragma  MEMORY_SIZE 


The  implementation-depencieiit  pragma  memory_SIZE  is  recognized  by  the  implementa¬ 
tion  but  has  no  visible  effect  The  implementation  restricts  the  argument  to  the  predefined 
value  in  the  package  SYSTEM. 


Pragma  OPT_FLAGS 


The  implementation-defined  pragma  OPT_FLAGS  provides  a  method  for  overriding  the 
optimization  parameters  defined  by  a  HAPSE  Ubraiy’s  configuration.  (See  “Configuring 
HAPSE”  on  page  12-2).  By  specifying  a  configuration  value  for  an  optimizer  parameter 
using  this  pragma,  the  given  value  is  observed  by  the  HAPSE  compiler  when  the  enclos¬ 
ing  unit  is  compiled  (regardless  of  the  value  specified  for  the  optimizer  parameter(s)  in  the 
library’s  configuration). 

The  OPT_FLAGS  pragma  takes  a  single  string  literal  as  an  argument.  This  string, 
enclosed  in  quotes,  should  contain  all  of  the  optimizer  flags  to  be  overridden  for  the  com¬ 
pilation,  along  with  the  value  to  be  observed.  The  literal  string  argument  must  take  the 
form: 


"^flag  -  value,  flag  -  value,  flag  -  value  ..." 

Seven  flags  are  recognized  by  the  HAPSE  compiler.  Many  of  these  flags  are  descnbed  in 
detail  in  Chapter  12  of  this  manual  and  arc  configurable  not  only  via  the  pragma,  but  also 
as  parameters  to  the  a  •  conflg  tool.  The  optimizer  flags  are: 

Ob  j  ect:s_to_opt  imize 

Lcx)ps_to_op  t  imi  z  e 

UnrolUimit 

Growth_limit 

Optimize_for_space 

Opt_class 

Noreorder 

For  example,  the  line: 

Pragma  OPT^FLAGS  (’^Growth^limit  -  200,  Unroll_limit  -  5"); 

will  optimize  a  total  of  200  objects,  and  will  use  a  loop  unrolling  limit  of  5  for  the  compi¬ 
lation  unit  whose  declarative  part  contains  the  precedmg  pragma.  These  values  will  over¬ 
ride  any  values  given  by  a  local  or  system  configuration  record  for  the  compilation. 

Compilation  units  that  do  not  contain  this  pragma  will  observe  the  optimizer  flag  values 
given  by  the  library’s  configuration.  Additionally,  all  optimizer  flags  that  are  not  given  as 
arguments  when  the  pragma  is  utilized  will  use  the  values  from  the  library’s  configuration. 


Pragma  OPT_LEVEL 


The  implementation-defined  pragma  OPT^LEVEL  controls  the  level  of  optimuation  per¬ 
formed  by  the  compiler.  This  pragma  takes  one  of  the  following  as  an  argument  MINI  - 
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MAL ,  GLOBAL ,  or  MAXIMAL.  The  default  is  MINIMAL  (equivalent  to  ada  -01).  The 
pragma  is  allowed  withiu  any  declarative  part  The  specified  optimization  level  will  apply 
to  all  code  generated  for  the  specifications  and  bodies  associated  with  the  immediately 
closing  declarative  part  For  more  about  optimization  see  Chapter  10  and  Chapter  12. 


Pragma  OPTIMIZE 

The  implementation-dependent  pragma  OPTIMIZE  is  recognized  by  the  implementation 
but  docs  not  have  an  effect  in  this  release.  See  the  -O  option  for  ada  for  code  optimiza¬ 
tion  options,  or  the  implementation-defined  pragma  OPT_LEVEL. 


Pragma  PACK 


The  implementation-dependent  pragma  PACK  causes  the  compiler  to  choose  a  non- 
aligned  representation  for  elements  of  composite  types.  Application  of  the  pragma  causes 
objects  to  be  packed  to  the  bit  level. 


Pragma  PAGE 


The  implementation-dependent  pragma  PAGE  is  implemented  as  described  in  Appendix  B 
of  the  Ada  RM. 


Pragma  POOL_CACHE_MODE 


The  implementation-defined  pragma  POOL_CACHE_MODE  defines  the  cache  mode  for  a 
memory  pool.  See  “Pragma  POOL_CACHE_MODE”  on  page  20-22  for  a  complete 
description. 
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Pragma  POOL_LOCK_STATE 


The  implementation-defined  pragma  POOL_LOCK_STATE  defines  the  lock  state  of  a 
memory  pool.  See  “Pragma  POOL_LOCK_STATE”  on  page  20-22  for  a  complete 
description. 


Pragma  POOL_PAD 

The  implementation-defined  pragma  P00L_PAD  sets  the  pad  for  a  STACK  memory  pool. 
See  “Pragma  POOL_PAD”  on  page  20-23  for  a  complete  description. 


Pragma  POOL__SIZE 


The  implemenution-defined  pragma  P00L_SIZE  permits  the  setting  of  the  size  for  a 
STACK  or  COLLECTION  memory  pool.  See  “Pragma  POOL_SIZE”  on  page  20-22  for  a 
complete  description. 


Pragma  PRIORITY 

The  implementation-dependent  pragma  PRIORITY  is  implemented  as  described  in 
Appendix  B  of  the  Ada  RM.  Priorities  range  from  0  to  255,  with  255  being  the  most 
urgent  See  “Pragma  TASK_PRIORmr  on  page  9-17  for  a  related  pragma. 


Pragma  QUEUING_POLICY 


The  implementation-defined  pragma  QUEUING_P0LICY  sets  the  entry  queuing  policy. 
See  “Pragma  QUEUING_POLICY”  on  page  20-2  for  a  complete  description. 


Pragma  RUNTIME_DI  AGNOSTICS 

The  implementation-defined  pragma  RUNTIME_DIAGNOSTICS  controls  whether  or^not 
the  run-time  emits  warning  diagnostics.  See  “Pragma  RUNTIME_DIAGNOSTICS  on 
page  20-1  for  a  complete  description. 


Pragma  SERVER_CACHE_SIZE 


The  implementation-defined  pragma  SERVER_CACHE_SIZE  sets  the  size  of  the  server 
cache.  See  “Pragma  SERVER_CACHE_SIZE”  on  page  20-2  for  a  complete  description. 
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Pragma  SHARED 

The  implementation-dependent  pragma  SHARED  is  recognized  by  the  implementation  but 
has  no  effect  on  the  current  release.  See  “Pragma  VOLATILE”  on  page  9-18  for  informa- 
tion  about  the  implementation-dejSned  pragma  VOLATILE. 


Pragma  SHARED_PACKAGE 


The  implementation-defined  pragma  SHARED_PACKAGE  provides  for  the  sharing  and 
communication  of  data  declared  within  the  specification  of  Ubrary-level  packages.  All 
variables  declared  in  the  specification  of  a  package  marked  pragma  SHARED_PACKAGE 
(henceforth  referred  to  as  a  shared  package)  are  allocated  in  shared  memory  that  is  created 
and  maintained  by  the  implementation  (the  variables  declared  in  the  body  (if  any)  of  such 
packages  are  not  shared).  The  pragma  can  be  applied  only  to  library-level  package  specifi¬ 
cations.  Each  package  specification  nested  in  a  shared  package  will  also  be  shared  and  all 
objects  declared  in  the  nested  packages  reside  in  the  same  shared  memory  segment  as  the 
outer  package. 

The  implementation  restricts  the  kinds  of  objects  that  can  be  declared  in  a  shared  package. 
Unconstrained  or  dynamically  sized  objects  cannot  be  declared  in  a  shared  package  and 
access  type  objects  cannot  be  declared  in  a  shared  package.  Additionally,  generic  instanti- 
ations  cannot  be  declared  within  a  shared  package.  If  any  of  these  restrictions  are  violated, 
a  warning  message  is  issued  and  the  package  is  not  shared.  These  restrictions  apply  to 
nested  packages  as  well.  Note  that  if  a  nested  package  violates  one  of  the  preceding 
restrictions,  it  prevents  the  sharing  of  all  enclosing  packages  as  well. 

Packages  that  require  initialization  should  not  be  marked  with  the  pragma  unless  the  usct 
is  prepared  to  deal  with  concurrency  issues.  The  compiler  no  longer  rejects  the  pragma  in 
these  cases;  however,  every  program  that  uses  the  shared  package  will  initialize  it  during 
program  elaboration.  Initialization  can  occur  as  a  result  of  an  explicit  initialization  by  the 
user  (e.g.,  a  integer  :  *  54  ; )  or  implicitly  due  to  an  object^s  representation  (an 
array  or  record  with  gaps).  The  compiler  issues  a  warning  message  in  either  case. 

Task  objects  are  allowed  within  shared  packages,  however,  the  tasks  as  well  as  the  data 
defined  within  those  tasks  are  not  shared. 

Pragma  shared_PACKAGE  accepts  as  an  optional  argument,  **params'\  that,  if  specified, 
must  be  a  string  constant  containing  a  comma-separated  list  of  system  shared  segment 
configuration  parameters,  as  defined  by  the  following: 

key-mzme  Identifies  the  system  shared  segment  key  to  be  used  in  subs^uent 

shmget  system  calls,  which  are  done  automatically  by  the  imple¬ 
mentation  in  configuring  the  shared  segment,  napte  is  considered 
to  be  a  file  name  which  will  be  translated  to  a  shared  segment  key 
using  the  ftok(  3C)  service.  By  default,  HAPSE  applies 
“key-  { absolute  HAPSE  library  path }  /.shmemJ package  jtame^"  to 
the  shared  package  and  creates  an  empty  file  by  that  name.  Note 
that  relative  path  names  may  be  specified  and  would  cause  key 
translation  to  be  dependent  on  the  user’s  current  working  direc¬ 
tory  when  program  execution  is  initiated.  If  name  is  a  numeric  lit¬ 
eral  (a  decimal  integer  or  Ada  octal-  or  hexadecimal-based  lit- 
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eral),  HaPSE  interprets  this  as  the  actual  system  key,  and  does 
not  translate  it  using  the  f  tok  service. 

ipc-(IPC_CREAT.  IPC^EXCL,  IPC^PRIVATE) 

Allows  the  user  to  specify  details  about  the  initialization  of  the 
shared  segment.  By  default,  HAPSE  applies 
ipo-  ( IPC_CREAT )  to  the  shared  package,  thereby  creating  the 
shared  segment  if  it  did  not  previously  exist  If  any  ipc  parame¬ 
ters  are  given,  they  entirely  replace  the  default  ipc  specification. 

SHM_RDONLY  Specifies  that  the  segment  is  available  only  for  READ  operations. 

HAPSE  defaults  shared  package  segments  to  READ/WRITE. 


CAUTION 

The  current  shared  memory  implementation  does  not  allow  the 
use  of  the  '  LOCK  and  '  UNLOCK  attributes  with  a  shm_RDONLY 
shared  memory  segment  Any  use  of  fiiese  attributes  with  a  pack¬ 
age  marked  SHM_RD0NLY  will  raise  program_error  at  run 
time. 


mode-n 


SHM_LOCAL 


SHM_LOCK 


SHM_HARD 


no_bsem 


Where  n  is  assumed  to  be  an  octal  number  defining  the  access  to 
the  shared  segment  By  default  HAPSE  applies  inode-644  to 
the  shared  package,  (owner  read/write,  group  read,  other  read). 
The  specified  value  for  mode  is  ORed  into  the  shn^gs  parameter 
that  HAPSE  uses  for  the  ahmget  ( 2 )  call.  Additional  bits  can  be 
supplied  via  mode  to  control  caching,  etc.  (e.g.,  “mode  - 
8#200644#”  would  specify  SHM_COPYBACK,  as  well  as  die  644 
mode).  For  more  information,  see  the  Power  UNIX  Programming 
Guide, 

Requests  that  pages  for  the  shared  segment  be  allocated  from  the 
local  memory  pool.  If  a  program  attempts  to  attach  to  a  segment 
which  has  been  allocated  from  local  memory  on  a  different  CPU, 
then  the  attachment  will  fail.  See  shmge't  ( 2 ) . 

Specifies  that  virtual  memory  pages  be  locked  into  physical  mem¬ 
ory  at  program  start-up  time.  Doing  this  makes  these  pages 
immune  to  swapping. 

When  used  in  conjunction  wifli  SHM_LOCAL,  specifies  that  pages 
for  the  shared  segment  must  be  allocated  from  the  local  memory 
pool.  If  pages  are  not  available  from  local  memory  then  the  signal 
SIGSEGV  is  delivered  to  the  process.  See  sbrngeh ( 2 ) . 

Prohibits  the  use  of  the  shared  package  lock  attributes  '  LOCK  and 
'  UNLOCK.  In  shared  packages  marked  with  this  parameter, 
binary  semaphore  space  is  not  initialized  in  the  shared  memory 
segment.  Any  attempt  to  make  use  of  the  lock  attributes  in  a 
shared  package  marked  with  no_bsem  will  raise 
PROGRAM_ERROR  at  run  time.  Unlike  RDONLY  shared  packages, 
packages  marked  by  no_bseiiihave  read/WRXTE  capability. 
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bind^n  Where  n  is  assumed  to  be  an  octal  number.  The  segment  will  be 

attached  to  the  physical  memory  address  specified  by  n. 


WARNING 

If  the  sbinbiiid.(  2 )  attempt  fails  due  to  EBUSY  or  EREGSTALE, 
the  implementation  will  ignore  the  error  and  continue,  assuming 
that  another  prf*grarn  has  already  bound  the  segment  to  the  desired 
location.  Shared  memory  segments  bound  to  physical  memory 
should  be  freed  manually  by  the  user  via  ipcrm<  1 ) . 


CAUTION 

By  default,  every  shared  package  that  is  available  for 
READ/WRITE  has  a  binary  semaphore  initialized  which  starts  12 
bytes  before  the  end  of  the  segment  and  extends  to  the  end  of  the 
segment.  If  a  shared  package  is  bound  to  a  device  using  the 
bind-  parameter,  be  aware  that  the  contents  of  these  bytes  may 
change  if  the  '  LOCK  and  '  UNLOCK  attributes  are  utilized.  The 
only  exceptions  are  those  shared  packages  which  are  defined  as 
SHM_RDONLY  or  those  marked  by  the  no_bsem  parameter.  In 
these  cases,  the  semaphore  space  is  not  initialized,  but  it  is  still 
present 


A  detailed  explanation  of  the  IPC  and  SHM  flags,  and  access  modes  may  be  found  in  “Ada 
Language  Program  Communication”  on  page  11-4  of  this  manual  and  the  following  man 
pages:  shmbind(  2 ) ,  shmget:(  2 ) ,  ipcs  ( 1 ),  ipcrm(  1 ) ,  and  chinod(  1 ) . 

The  SHARED_PACKAGE  pragma  must  appear  within  the  specification  of  the  library-level 
package.  The  pragma  may  also  be  repeated  in  the  package  body  to  allow  the  user  to  over¬ 
ride  the  shared  memory  configuration  parameters  that  were  associated  with  the  pragma  in 
the  specification.  Additionally,  these  configuration  parameters,  as  defined  before,  may 
also  be  specified  at  link  time  to  a .  Id,  via  the  -shmem  “paramo”  option,  where  '^params 
is  defined  as  before  with  the  addition  that  the  first  item  in  the  list  must  be  the  name  of  a 
shared  package.  If  this  option  is  used,  then  it  replaces  all  previous  information  that  may 
have  been  provided  with  all  pragmas  for  that  package. 

A  more  detailed  example  of  shared  package  usage  is  given  in  “Ada  Language  Program 
Communication”  on  page  11-4. 

With  the  valid  application  of  pragma  SHARED^?  ACKAGE  to  a  library-level  package,  the 
following  assumptions  can  be  made  about  the  objects  declared  in  the  package: 

•  The  lifetime  of  such  objects  is  greater  than  the  lifetime  defined  by  the  com¬ 
plete  execution  of  a  single  program. 

•  The  lifetime  of  such  objects  is  guaranteed  to  extend  from  the  elaboration  of 
the  shared  package  by  the  first  concurrent  program  until  the  termination  of 
execution  of  the  last  concurrent  program. 
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In  tile  preceding  assumptions,  a  concurrenf  program  is  defined  to  be  any  Ada  program  that 
elaborates  the  body  of  a  shared  package,- whose  span  of  execution,  from  elaboration  of 
such  a  package  to  tmnination,  overlaps  that  of  anotiicr  such  program. 

In  actuality,  the  shared  memory  segments  created  by  these  programs  remain  even  after  the 
last  concurrent  program  has  exited.  The  values  of  objects  within  these  segments  remain 
valid  until  the  segment  is  destroyed,  or  until  the  system  is  rebooted.  Segme^  may  Iw 
eiqilicitly  removed  through  the  shared  memory  service  shmctl,  to  which  an  interface  is 
provided  in  the  HAPSE  package  ahared_jiieinory_support.  Alternatively,  the  user 
may  obtain  information  about  active  shared  memory  segment,  through  the  ipcs  ( 1 )  util¬ 
ity.  These  segments  may  be  removed  via  tiic  ipcrm(  1 )  utility. 

Programs  tiiat  attenqit  to  reference  the  contents  of  objects  declared  in  shared  packages  that 
have  not  been  implicitly  or  explicitly  initialized  ate  technically  erroneous  as  defined  by 
tile  RM  (3.11(18)).  This  implementation,  however,  does  not  prevent  such  references  and, 
in  fact  expects  them. 

Ihe  preceding  discussion  describes  the  intent  that  several  Ada  programs  may  be^  con¬ 
tinue,  and  complete  their  execution  simultaneously,  with  the  contents  of  the  variables  in 
the  shared  packages  consistent  with  the  execution  of  those  programs. 

The  association  of  a  system  shared  memory  segment  with  the  shared  pac^ge  occurs  dur¬ 
ing  the  elaboration  of  the  package  body.  If  this  association  should  fail  due  to  system 
shared  memory  constraints,  access,  or  improper  use  of  shared  memory  confipiration 
parameters,  an  error  message  is  issued  and  the  PROGRAH_ERROR  exception  is  raised. 

HAPSE  has  provided  semaphore  operations  so  that  programs  can  define  critical  sections 
to  reference  and  update  variables  within  the  shared  packages.  See  “Implementation- 
Dependent  Attributes”  on  page  9-18  for  a  description  of  the  implementation-defined 
attributes  P '  LOCK  and  P '  UNLOCK. 


Example: 

--  The  following  illustrates  proper  usage  of  the  'params^'  argument 
--  supplied  to  the  Pragma  SHARED_PACKAGE . 

package  sharecLpack  is 
dummy  :  integer; 

procedure  do_nothing ;  ^ 

pragma  sharedUpaokage  (‘Icey-S,  lpc-IPC_CREA'r,  no.bsem,  SHH_LOCK'); 

end  shared_pack; 

package  body  shared_pack  is 
procedure  do_nothing  is 
begin 

null; 

end  do_nothing; 
end  shared_pack; 


Pragma  SHARE_BODY 


The  implementation-defined  pragma  SHARE_BODY  is  used  to  indicate  whether  or  not  an 
instantiation  is  to  be  shared.  The  pragma  may  reference  the  generic  unit  or  the  instantiated 
unit  When  it  references  a  generic  unit  it  sets  sharing  on/off  for  all  instantiations  of  the 
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generic,  unless  overridden  by  specific  SHAREJODY  pragmas  for  individual  instantia¬ 
tions.  When  it  references  an  instantiated  unit,  sharing  is  on/off  only  for  that  unit.  The 
default  is  to  share  all  generics  that  can  be  shared,  unless  the  unit  uses  pragma  INLINE. 
See  “Shared  Generics”  on  page  7-6  for  a  complete  list  of  restrictions. 

Pragma  SHARE_B0DY  is  allowed  only  in  the  following  places:  immediately  withm  a 
declarative  part,  immediately  within  a  package  specification,  or  after  a  library  unit  in  a 
compilation,  but  before  any  subsequent  compilation  unit  The  form  of  this  pragma  is 

pragma  SHARE_BODY  ( generic jiame,  boolean Jiteral) 

Note  that  a  parent  instantiation  is  independent  of  any  individual  instantiation;  therefore, 
recompilation  of  a  generic  with  different  parameters  has  no  effect  on  other  compilations 
that  reference  it  The  unit  that  caused  compilation  of  a  parent  instantiation  need  not  be 
referenced  in  any  way  by  subsequent  units  that  share  the  parent  instantiation. 

Sharing  generics  causes  a  slight  execution  time  penalty  because  all  type  attributes  must  be 
indirectly  referenced  (as  if  an  extra  calling  argument  were  added).  However,  it  substan¬ 
tially  reduces  compilation  time  in  most  circumstances  and  reduces  program  size. 


Pragma  SHARE.MODE 

The  implementation-defined  pragma  SHARE_MODE  is  provided  to  allow  users  to  set  the 
sharejnode  for  a  compilation  unit  firom  within  the  Ada  source  code.  The  format  of  the 
pragma  is: 

pragma  SHARE_^ODE  (sharejnode)  ; 
where  sharejnode  is  one  of:  SHARED,  NON_SHARED,  or  BOTH. 

This  pragma  is  allowed  immediately  within  the  outermost  declarative  context  of  a  library- 
level  compilation  unit  If  applied  to  a  specification,  it  also  applies  to  the  body  (and  any 
separate  bodies)  corresponding  to  that  compilation  umt.  If  applied  to  a  body,  it  also 
applies  to  any  separate  bodies  corresponding  to  that  compilation  umt,  but  not  the  specifi¬ 
cation.  The  pragma  may  be  specified  for  the  specification,  body,  and  separate  bodies  of 
the  same  library-level  package  or  subprogram. 

If  the  pragma  is  applied  to  a  generic,  it  also  applies  to  all  instantiations  of  that  generic  that 
exist  in  the  same  HAPSE  library. 


Pragma  STORAGE_UNIT 


The  implementation-dependent  pragma  STORAGE_UNIT  is  recognized  by  the  implemen¬ 
tation  but  has  no  visible  effect.  The  implementation  restricts  the  argument  to  the  pre¬ 
defined  value  in  the  package  SYSTEM. 
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Pragma  SUPPRESS 

The  implementation-dependent  pragma  SUPPRESS  in  the  single  parameter  form  is  sup¬ 
ported  applies  from  the  point  of  occurrence  to  the  end  of  the  innermost  enclosing 
block.  DIVISION^CHECK  and  OVERFLOW_.CHECK  for  floating-point  types  wiU  reduce 
the  amount  of  overhead  associated  with  checking*  but  is  not  fiilly  suppressible.  The  dou¬ 
ble  parameter  form  of  the  pragma*  with  a  name  of  an  object*  type,  or  subt)^  is  recog¬ 
nized*  but  has  no  eflect 


Pragma  SUPPRESS^ALL 


The  implementation-defined  pragma  SDPPRESS_ALL  gives  pennission  to  the  implemen¬ 
tation  to  suppress  all  run-time  checks.  Pragma  SUPPRESS_ALL  does  not  have  any 
parameters.  It  is  allowed  to  appear  immediately  within  a  declarative  part  or  immediately 
within  a  package  specification.  Its  effects  are  equivalent  to  a  list  of  SUPPRESS  pragmas, 
each  naming  a  different  check. 


Pragma  SYSTEM_NAME 


The  implementation-dependent  pragma  SYSTEM_NAME  is  recognized  by  the  implementa¬ 
tion  but  has  no  visible  effect.  The  implementation  provides  only  one  enumeration  value 
for  SYSTEM_NAME  in  the  package  SYSTEM. 


Pragma  TASK_CPU_BIAS 

The  implementation-defined  pragma  TASK_CPU_BIAS  is  used  to  set  the  CPU  assign¬ 
ments  for  a  given  BOUND  task.  See  “Pragma  TASK_CPU_BIAS”  on  page  20-8  for  a  com¬ 
plete  description  of  task  CPU  assignments. 


Pragma  TASK_PRIORITY 

The  implementation^lefined  pragma  TASK_PRIORITy  is  used  to  set  the  scheduling  pri¬ 
ority  1)  for  a  given  task  within  the  server  group  and  2)  for  entry  queuing.  It  also  sets  the 
operating  system  priority  for  BOUND  tasks.  See  “Priorities”  on  page  18-3  and  Pragma 
TASK_PRIORITY”  on  page  20-7  for  a  complete  description  of  task  priorities. 


Pragma  TASK_QUANTUM 


The  implementation-defined  pragma  TASK^QUANTUM  is  used  to  set  the  task  time-slice 
duration  for  a  given  task.  See  “Pragma  TASK_QUANTUM”  on  page  20-9  for  a  complete 
description  of  task  time-slicing. 
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Pragma  TASK_WEIGHT 

The  implementation-defined  pragma  TASK_WEIGHT  specifies  the  weight  of  a  task.  See 
“Pragma  TASK_WEIGHT”  on  page  20-5  for  a  complete  description. 


Pragma  VOLATILE 


The  implementation-defined  pragma  VOLATILE  accepts  a  list  of  simple  variable  names, 
which  the  compiler  assumes  to  occupy  volatile  storage  bases.  All  accesses  of  these  vari¬ 
ables  will  result  in  memory  references.  Pragma  VOLATILE  should  be  used  on  any  vari¬ 
able  that  may  be  accessed  concurrently  by  different  threads  of  a  program,  e.g.,  a  variable 
shared  between  tasks. 

V 

An  example  of  a  use  of  pragma  VOLATILE  follows: 
pragma  VOLATILE  (  namel ,  name2  ) ; 


Implementation-Dependent  Attributes 


HAPSE  has  defined  the  following  attributes  for  use  in  conjtmction  with  the  implementa¬ 
tion-defined  pragma  shared_package: 

P'KEY 
P'SHM_ID 
P'LOCK 
P ' UNLOCK 

where  the  prefix  P  denotes  a  package  marked  with  pragma  SHARED_PACKAGE. 

The  '  KEY  attribute  is  an  overloaded  function  without  parameters  that  returns  the  key  used 
to  identify  the  system  shared  segment  associated  with  the  package.  One  specification  of 
the  function  returns  the  predefined  type  string,  and  returns  a  value  specifying  the  file 
name  used  in  the  key  translation  (ftok(  3C)).  If  an  integer  literal  key  was  specified  in 
the  pragma  SHARED_PACKAGE  parameters,  this  function  returns  a  null  string.  The  other 
specification  of  the  function  returns  the  predefined  type  universal_integer,  and 
returns  a  value  specifying  the  translated  integer  key.  The  latter  form  of  the  function  will 
raise  the  predefined  exception  PROGRAM^ERROR  if  the  shared  package  body  has  not  yet 
been  elaborated. 

The  '  SHM_ID  attribute  is  a  function  without  parameters  that  returns  the  shared  memory 
segment  identifier  for  the  system  shared  memory  segment  associated  with  the  shared 
package  P.  This  identifier  corresponds  to  the  identifier  which  is  returned  by  the  shared 
memory  service  shmget  upon  creation  of  the  shared  package. 

The  '  SHM_ID  attribute  will  raise  pR0GRAM_ERR0R  if  the  call  to  shmget  failed  when 
the  segment  associated  with  the  shared  package  P  was  created. 
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The  '  LOCK  and  '  UNLOCK  attributes  are  procedures  without  parameters  that  mampulate 
the  “state”  of  a  shared  package.  HAPSE  defines  aU  shared  packages  to  have  two  states: 
LOCKcd  and  UNLOCKed.  Upon  return  from  the  '  LOCK  procedure,  the  state  of  the  package 
will  be  LOCKed.  If  upon  invocation,  '  LOCK  finds  the  state  already  LOCKed,  it  will  wait 
until  it  becomes  UNLOCKed  before  altering  the  state  and  returning.  '  UNLOCK  sets  the 
state  of  the  package  to  UNLOCKed  and  then  returns.  At  the  point  of  unlocking  the  pack¬ 
age,  if  another  process  waiting  in  the  '  LOCK  procedure  has  a  more  favorable  operating 
system  priority,  the  system  will  immediately  schedule  its  execution. 

Note  that  if  '  LOCK  is  waiting,  it  may  be  interrupted  by  the  HAPSE  run-time  system  s  time 
slice  for  tables  which  may  cause  another  task  within  the  process  to  become  active.  Eventu¬ 
ally,  HAPSE  will  again  transfer  control  to  the  '  LOCK  procedure  in  the  original  task,  and  it 
will  continue  waiting  or  return  to  the  task. 

The  state  of  the  package  is  meaningful  only  to  the  ^  LOCK  and  '  UNLOCK  attribute  proce¬ 
dures  that  set  and  query  the  state.  A  LOCK  state  dWS  UQX  prgVgnt  gQngymm  mm  to 
objects  in  the  shared  package.  These  attributes  provide  indivisible  operations  only  for  the 
setting  and  testing  of  impUcit  semaphores  that  could  be  used  to  control  access  to  shared 
package  objects. 


CAUTION 

The  current  shared  memory  implementation  does  not  allow  the 
use  of  the  '  LOCK  and  '  UNLOCK  attributes  with  a  shm_rdonly 
shared  memory  segment  or  a  shared  package  marked  with  the 
no_bsem  parameter. 


HAPSE  provides  die  package,  shared  jaemory_support.  This  package  conteins  Ada 
type,  subprogram  definitions,  and  interfaces  to  aid  the  user  in  manually  interfacing  to  the 
shared  memory  system  services. 

This  includes: 

•  System  dafines  and  records  layouts  as  defined  by  the  C  programming  lan¬ 
guage  include  files,  <sys/shm.h>  and  <sys/ipc.h>. 

•  Interface  specifications  to  shared  memory  system  calls:  shmbind, 
shmget,  shmat,  shmctl,  shmdt. 

•  Interface  specifications  to  the  system’s  binary  semaphore  operators: 
bseitiget,  bseinfree,  lockbinsem,  unlockbinsem,  clockbin* 
seitL 


Specification  of  Package  System 


package  system  is 

type  name  is  ( KARRI S_POWER)  ; 

system^name  constant  name  :  *■  KARRI S__POWER  ; 
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System- Dependent  Named  Numbers 

-  -2_147_483_647  -  1  ; 

-  2_147_483_647  ; 

-  2_147_483_648  ; 

-  4^294^967^296  ; 

-  15  ; 

-  31  ; 

-  2.0  (-31)  ; 

-  0.01  ; 

--  Storage- related  Declarations 
type  address  is  private  ; 
no_addr  :  constant  address  ; 


min^int 

maix^int 

ina3C_nonbinary_raodulus 
max_^)inary_juodulus 
max_digits 
max__mant  is  sa 
fine_delta 


constant 
constant 
constant 
constant 
constant 
constant 
constant 
constant ■ 


storage_unit  :  constant  8  ; 
memory_size  constant  :*■  3_^221_225_469  ; 

--  Other  system- Dependent  Declarations 
subtype  priority  is  integer  range  0  . .  255  ; 

subtype  max_„rec_size  :  integer  268435455;  ■-  16#0FFFFPFF# 


pragma  suppress  (  elciboration^check  ) ; 


--  The  following  functions  provide  conversions  to  address" 
from  integer  values. 

--  Note:  the  function  ’'physical^address'  was  misnamed,  and  will 
--be  deleted  in  subsequent  releases.  Use  '^logical_address" . 

function  logical_address  (i  :  integer)  return  address  ; 
function  physical^address  (i  :  integer)  return  address  renames 
logical_addres8  ; 


--  The  following  function  should  ONLY  be  used  to  supply  a 
--  machine  address  to  an  object's  address  clause  statement. 

--  The  parameter  is  an  integer  describing  the  physical  machine 
--  address  of  the  object. 

--  Optimization  of  subsequent  references  to  the  object  with  the 
--  address  clause  will  result  if  the  parameter  to  this  function 
--  is  an  integer  literal. 

--  The  form  of  the  function  that  takes  a  string  argument  is  provided 
--  to  ease  the  specification  of  machine  addresses  which  have  the 
--  high  bit  set.  For  example, 


for  clock  use  at  machine_address( 16 #9 6002000#")  ; 

--  In  this  case,  the  specified  argument  must  be  a  string  literal 
--  which  may  have  the  high  bit  set,  but  is  otherwise  acceptable 
--to  integer 'value( ) . 
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function  nmehina  address  (i  :  integer)  return  addrees  ; 


function  machdlne^addreBa  < 

function  (a,  b  : 

function  '<*  (a,  b  : 

function  (a,  b  : 

function  *<-'  (a,  b  : 


:  string)  return  address  ; 

address)  return  boolean  ; 
address)  return  boolean  ; 
address)  return  boolean  ; 
address)  return  boolean  ; 


function 
function  *+' 
function 


(a,  b  :  address)  return  integer  ; 

(a  :  address  ;  incr  :  integer)  return  address  ; 
(a  :  address  ;  deer  :  integer)  return  address  ; 


function  addr_gt  (a, 
function  addr_lt  (a, 
function  addr_ge  (a, 
function  addr  Jle  ( a , 


b  :  address)  return 
b  :  address)  return 
b  :  address)  return 
b  :  address)  return 


boolean  renames  ; 
boolean  renames  *<'  ; 
boolean  renames  ; 

boolean  renames  ; 


function  addr_dl£f  (a,  b  :  addres*)  return  integer  renames  ; 
function  incr_addr  (a  :  address  ;  incr  :  integer)  return  address 
renames  ; 

function  deor_addr  (a  :  address  ;  deer  :  integer)  return  address 
renames  ; 

em  ; 


Restrictions  on  Representation  Ciauses 

Pragma  PACK 


Pragma  PACK  is  fiiUy  supported.  Objects  and  components  are  packed  to  the  nearest  and 
sm^est  bit  boundary  when  pragma  PACK  is  appbed. 


Length  Clauses 


The  specification  T '  SIZE  is  fully  supported  for  all  scalar  and  composite  types,  except  for 
floating  point  For  floating-point,  access,  and  task  types,  the  supplied  static  expression 
must  conform  to  an  existing  supported  machine  representation. 


Type 

Size 

floatingpoint 

32  or  64 

access 

32 

task 

32 

T '  SIZE  applied  to  a  composite  type  will  cause  compression  of  scalar  component  types 
and  the  g{^>s  between  the  components.  T '  SIZE  applied  to  a  composite  type  whose  com¬ 
ponents  are  composite  types  does  not  imply  compression  of  the  inner  composite  objects. 
To  achieve  such  compression,  the  implementation  requires  explicit  application  of  T '  SIZE 
or  pragma  PACK  to  the  inner  composite  type. 
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Composite  types  which  contain  components  that  have  had  T '  SIZE  applied  to  them,  will 
adhere  to  the  specified  component  size,  even  if  it  causes  alignment  of  components  on  non- 
STORAGE_UNlT  boundaries. 

The  size  of  a  non*component  object  of  a  type  whose  size  has  been  adjusted,  via  T '  SIZE 
or  pragma  PACK,  will  be  exactly  the  specified  size;  however,  the  implementation  will 
choose  an  alignment  for  such  objects  that  provides  optimal  performance. 


Record  Representation  Clauses 

The  simple  expression  following  the  keywords  “at  mod”  in  an  alignment  clause  speci¬ 
fies  the  STORAGE_UNIT  alignment  restrictions  for  the  record  and  must  be  one  of  the  fol- 
lowing  values:  1 , 2, 4  or  8. 

The  simple  expression  following  the  keyword  “at”  in  a  component  clause  specifies  the 
STORAGE_UNIT  (relative  to  the  beginning  of  the  record)  at  which  the  following  range 
is  applicable.  The  static  range  following  the  keyword  range  specifics  the  bit  range  of  the 
component.  Components  may  overlap  word  boundaries  (4  STORAGE_UNITs).  Compo¬ 
nents  that  are  themselves  composite  types  must  be  aligned  on  a  STORAGE__UNlT  boimd- 
ary. 

A  component  clause  applied  to  a  component  that  is  a  composite  type  does  not  imply  com¬ 
pression  of  that  component  For  such  component  types,  the  implementation  requires  that 
T '  SIZE  or  pragma  PACK  be  applied,  if  compression  beyond  the  default  size  is  desired. 


Address  Clauses 

Address  clauses  are  supported  only  for  variables,  constants,  and  task  entries. 

For  variables  and  constants,  both  logical  and  machine  addresses  are  supported.  A  logical 
address  refers  to  a  virtual  memory  address  in  the  execution  program’s  address  space.  A 
machine  address  refers  to  a  physical  memory  address. 


Logical  address  clauses 

•  The  function  LOGlCAL_ADDRESS  is  defined  in  the  package  SYSTEM  to 
provide  conversion  from  INTEGER  values  to  ADDRESS  values  for  logical 
addresses  only. 

•  Both  static  and  variable  logical  addresses  are  supported. 

•  The  value  supplied  to  the  address  clause  must  be  a  valid  logical  address  in 
the  user’s  program. 

Machine  address  clauses 

•  When  a  machine  address  is  desired,  the  expression  supplied  on  the  address 
clause  must  be  an  invocation  of  the  function  machine_ADDRESS,  found 
in  package  SYSTEM.  Any  odier  expression  supplied  to  the  address  clause 
will  cause  it  to  be  interpreted  as  a  logical  address. 
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•  RAth  statir.  anri  variahift  machine  addresses  aiC  SUPPOltcd. 

•  If  the  argument  to  machine_address  is  an  integer  literal,  then  static 
address  translation  can  occur,  thereby  removing  any  additional  overhead 
involved  in  accessing  the  variable  at  run  time. 

•  In  order  to  use  machine  address  clauses,  you  must  have  the  p^SHMBINE 
privilege. 


WARNING 

It  is  the  user’s  responsibility  to  ensure  that  the  supplied  address  is 
a  valid  physical  memory  address. 

Memory  copies  done  through  address  clauses  will  require  a  bus 
access  for  each  word. 


Machine  addresses  clauses  are  implemented  via  system  shared  memory  segments,  which 
are  bound  to  the  specified  physical  memory  address  at  elaboration  time.  These  shared 
memory  segments  are  removed  at  die  end  of  normal  execution  of  a  program. 


Interrupts 


Interrupt  entries  (signals  and  hardware  interrupts)  are  supported.  This  feature  allows  Ada 
programs  to  bind  an  operating  system  signal  to  an  interrupt  entry  by  using  a  for  clause 
with  a  signal  number.  Two  may  not  posses  a  binding  to  the  same  interrupt  source  at 

the  same  time;  if  this  is  attempted,  program^error  will  be  raised.  Interrupt  entries  must 
not  have  any  parameters  and  can  be  called  explicitly  by  the  program.  See  the  chapter  on 
taglr  interrupt  entries  in  the  run-time  section  for  more  information. 


Other  Representation  Implementation-Dependencies 
Restrictions  to  the  ADDRESS  Attribute 

The  ADDRESS  attribute  is  not  supported  for  the  following  entities:  static  constants,  pack¬ 
ages,  tasks,  and  entries.  Application  of  the  attribute  to  these  entities  generates  a  compile 
time  warning  and  returns  a  value  of  0  at  run  time. 

Restrictions  to  Alignment  of  Types 


Like  the  size,  the  alignment  of  a  data  type  is  a  property  of  the  type.  If  a  type  requires  align¬ 
ment,  then  the  address  of  any  object  of  the  type  modulo  the  alignment  value  is  required  to 
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be  zero.  This  is  the  same  as  saying  that  the  address  must  be  a  multiple  of  the  alignment 
value. 

For  example,  if  an  object  is  word  (4-byte)  aligned,  its  address  must  be  a  multiple  of  4 
bytes.  The  address,  16#7fff439c#  is  a  multiple  of  4  bytes,  so  it  is  word-aligned.  The 
address,  16#7£Bf439b#  is  not,  however,  because  16#b#  mod  4  is  3. 

Ideally,  representation  specifications  and  length  clauses  would  size  and  align  any  data  type 
to  any  number  of  bits.  However,  there  are  actually  underlying  hardware  and  compiler 
impiomftntatinn  choices  that  impose  some  restrictions.  For  die  Series  6000  architecture, 
HAPSE  imposes  restrictions  on  the  alignment  of  several  specific  types  or  classes  of  types. 
These  restrictions  are  outlined  in  the  following  sections. 


Access  and  Task  Type  Alignment 

In  order  to  provide  the  fastest  access  possible  when  dereferencing  access  types,  HAPSE 
requires  that  all  objects  of  access  types  be  aligned  on  a  word  (4-byte)  address  boundary. 
Because  HAPSE  implements  task  types  using  an  access  type,  it  also  requires  that  task 
types  be  aligned  on  a  word  boxmdary.  The  compiler  issues  an  error  message  if  you  try  to 
^gn  a  task  or  access  type  on  any  other  alignment  boundary. 


FLOAT  and  LONG^FLOAT  Type  Alignment 

In  the  current  version  of  the  HAPSE  Ada  compiler,  the  interface  between  the  front  end  and 
code  generator  imposes  an  alignment  restriction  of  at  least  byte  alignment.  For  this  rea¬ 
son,  objects  of  any  floating-point  type  and  objects  of  composite  types  containing  floating¬ 
point  objects  must  be  byte-aligned  as  a  minimum.  In  order  to  provide  more  efficient  code 
and  avoid  misaligned  access  exceptions  on  the  Series  6000  architecture,  the  HAPSE  Ada 
compiler  will  try  to  provide  for  optimal  alignment  of  float  and  long  float  objects.  The 
optimal  alignment  for  single-precision  floats  is  4  bytes,  and  for  long  floats  is  8  bytes.  You 
may  use  pragma  PACK  or  a  representation  specification  to  force  the  alignment  to  be  as 
small  as  one-byte,  but  the  compiler  will  reject  any  representation  specification  that  tries  to 
bit  align  a  floating-point  object 


Integer,  Fixed-Point,  and  Enumeration  Type  Alignment 

The  HAPSE  Ada  compiler  imposes  no  minimal  alignment  restrictions  on  any  integer  type, 
or  any  type  whose  underlying  implementation  is  that  of  an  integer,  such  as  fixed-point  and 
enumeration  types.  Objects  of  these  types  may  be  packed  to  the  bit  level  resulting  in  bit 
alignment 

In  Older  to  maximize  performance  and  avoid  misaligned  access  exceptions  on  Series  6000 
architectures,  the  HAPSE  Ada  compiler  will  try  to  align  objects  of  integer,  fixed-point 
and  enumeration  types  on  their  optimal  alignment  boundary.  This  boundary  is  a  multiple 
of  the  size  of  the  type  in  question.  For  example,  integers  will  be  given  4-byte  optimal 
alignment  and  tiny  Jnteger  objects  will  be  one-byte  aligned. 

The  optimal  alignment  may  be  overridden  with  pragma  PACK  or  by  utilizing  a  representa¬ 
tion  specification  to  force  smaller  alignments. 


Q.OA 
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Composite  Type  Alignment 

The  minimal  and  optimal  alignments  for  record  and  array  types  is  determined  by  taking 
the  maximum  of  the  alignment  restrictions  imposed  by  the  component  types  involved. 
For  example,  if  a  record  type  contains  an  array  of  LONG_FLOAr  objects,  then  the  array 
and  the  enclosing  record  will  be  given  an  optunal  aligmnent  restriction  of  64  bits.  This 
may  be  reduced  to  a  minimal  alignment  restriction  of  8  bits  by  applying  pragma  PACK  or  a 
length  clause  to  the  array  type. 

Note  that  although  array  components  may  be  packed  to  a  size  which  is  not  a  multiple  of 
their  alignment  restriction,  die  HAPSE  Ada  compiler  will  force  padding  to  be  allocated 
after  each  component  such  that  the  next  component  begins  on  an  alignment  boundary.  For 
example,  ctmsider  the  following  types: 

type  BITTY_REC  is 
record 

BOAT  :  float  ; 

SINKING  :  boolean  ; 
end  record  ; 

for  BITTY_REC'size  use  33  ; 

type  BR.jaiRAY  is  array  (1  .  .  5 )  of  BITTY_REC  ; 

X  :  BR_ARRAY  ; 

At  first  glance,  it  might  seem  that  BR_ARRAY’size  should  be  165  (33  *  5)  bits,  but 
because  the  float  element,  BOAT,  requires  at  least  8-bit  alignment,  BR_ARRAY  will  be 
sized  to  200  (40  *  5)  bits.  This  is  because  alignment  padding  is  allocated  between  each 
element  as  shown  in  Figure  9-1. 


X(1) 

7 

bit 

pad 

X(2) 

7 

bit 

pad 

X(3) 

7 

bit 

pad 

•  •  • 

^  33  ^ 

7  33  — 7  ► 

40 - —  *  40 


Figure  9-1 .  8-Blt  Alignment  for  Composite  Type 

If  the  BnTY_REC  type  did  not  have  the  length  clause  of  33  bits  on  it  this  padding  would 
occur  differently,  because  the  compiler  would  choose  to  optimally  align  each  element  of  a 
BR_ARRAY.  The  float  element  of  a  BnTY_REC,  BOAT,  forces  an  optimal  alignment  of 
32  bits,  so  each  element  of  a  BR_ARRAY  would  be  aligned  on  a  word  boundary,  as  shown 
in  Figure  9-2. 
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X(1) 

24 

bit 

pad 

X(2) 

24 

bit 

pad 

X(3) 

24 

bit 

pad 

40  — »^24 ►-*—  40  *  *24^ 


Figure  9-2.  32-Blt  Alignment  for  Composite  IVPO 


The  pad  between  each  element  allows  optimal  code  generation  when  accessing  the 
float  eleniftnts  and  avoids  misaligned  access  exceptions  as  well. 

Note  that  dynamic  record  types  contain  internal  fields  that  may  also  increase  die  minimum 
alignment  restrictions  to  32  bits.  In  most  cases,  these  types  may  not  have  representation 
specifications  applied  to  them. 


Conventions  for  Implementation-Generated  Names 


Implementation-generated  names  do  not  exist 


Unchecked  Programming 
Restrictions  on  UNCHECKED_CONVERSiON 

The  predefined  generic  function  onchecked.CONVERSION  cannot  be  instantiated  with 
a  target  type  that  is  an  unconstrained  record  type  with  discriminants. 


Implementation  of  UNCHECKED_CONVERSION 


The  following  describes  the  transfer  of  data  between  the  source  and  target  operands  when 
performing  unchecked  conversion.  When  possible,  the  implementation  may  optimize  the 
conversion  operation  such  that  transfer  of  data  does  not  actually  occur. 


Justification 


The  implementation  considers  all  objects  of  simple  types  to  be  “right  justified  within  the 
storage  allocated,  and  all  objects  of  composite  types  to  be  “left  justified”.  If,  for  alignment 
reasons,  an  object  is  placed  in  storage  which  is  larger  than  the  object’s  '  SIZE  value,  the 
significant  bits  of  an  object  of  a  simple  type  will  be  placed  in  the  low  order  bits  of  storage. 


Implementation-Dependent  Characteristics 


right  justified^  with  any  padding  in  the  high  order  bits.  Likewise,  should  an  object  of  a 
composite  type  be  allocated  storage  which  is  larger  than  die  type  s  '  SIZE,  the  significant 
bits  will  be  placed  in  the  high  order  bits,  and  any  padding  will  be  placed  in  the  low  order 
bits. 


Simple  Type  to  Simple  T^pe  Conversions 

For  all  access,  tAsk  and  scalar  types,  unchecked  conversion  is  implemented  using  the  most 
efficient  MOVE  instruction  to  move  a  1, 2, 4  or  8  byte  object  to  its  destination.  However,  a 
BIT_MOVE  will  be  used  if  the  type  has  explicidy  been  given  a  '  SIZE  which  is  not  a 
power  of  two. 

If  the  sizes  of  the  source  and  target  differ,  then  the  smallest  size  is  used. 

If  the  target  has  a  larger  size  than  the  source,  the  source  is  moved  to  the  low  order  bits  of 
the  target.  If  the  target  type  is  signed,  then  the  high  bit  of  the  source  is  sign  extended 
through  the  high  bits  of  the  target  Otherwise,  the  high  order  bits  of  the  target  are  zero- 
filled. 

If  die  target  has  a  smaller  size  than  the  source,  the  low  order  bits  of  the  source  are  copied 
to  the  target 


Composite  Type  to  Composite  Type  Conversions 

All  conversions  logically  occur  by  moving  bits  from  the  source  to  the  target  starting  at  the 
highest  order  bit  of  the  source  and  target 

If  the  su^s  of  the  source  and  target  differ,  then  the  smallest  size  is  used. 

If  the  target  has  a  larger  size  than  the  source,  the  source  is  moved  to  the  high  order  bits  of 
the  target  and  the  low  order  bits  of  die  target  are  zero  filled. 

If  the  target  has  a  smaller  size  than  the  source,  the  high  order  bits  of  the  source  are  copied 
to  the  target. 


Simple  Type  to  Composite  Type  Conversions 

Conversions  from  simple  types  to  composite  types  are  implemented  by  moving  the  low 
order,  right  justified,  bits  of  the  source  to  the  high  order,  left  justified,  bits  of  the  target. 

If  the  sizes  of  the  source  and  target  differ,  then  the  smallest  size  is  used. 

If  the  target  has  a  larger  size  than  the  source,  the  source  is  moved  to  the  high  order  bits  of 
the  target,  and  the  low  order  bits  of  the  target  are  zero-filled. 

If  the  target  has  a  smaller  size  than  the  source,  the  low  order  bits  of  the  source  are  copied 
to  the  target 
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Composite  Type  to  Simple  Type  Conversions 

Conversions  from  composite  types  to  simple  types  are  implemented  by  moving  the  high 
order,  left  justified,  bits  of  the  source  to  the  low  order,  right  justified,  bits  of  the  target 

If  the  sizes  of  the  source  and  target  differ,  then  the  smallest  size  is  used. 

If  the  target  has  a  larger  size  than  the  source,  the  source  is  moved  to  the  low  order  bits  of 
the  target  If  the  target  type  is  signed,  then  the  high  bit  of  the  source  is  sign  extended 
through  the  high  bits  of  the  target.  Otherwise,  the  high  order  bits  of  the  target  are  zero 
filled. 

If  the  target  has  a  smaller  size  than  the  source,  the  high  order  bits  of  the  source  are  copied 
to  die  target 


UNCHECKED_DEALLOCATtON 


DNCHECKED_DEALLOCATION  is  supported.  Currently,  UNCHECKED_DEALLOCATION 
does  not  have  an  effect  on  access  objects  that  designate  tasks.  / 


Implementation  Characteristics  of  I/O  Packages 


Implementation-Dependent  Characteristics  of  DIRECT  I/O 

Instantiations  of  DIRECT_IO  use  the  value  MAX_REC_SIZE  as  the  record  size 
(expressed  in  STORAGE_UNlTs)  when  the  size  of  ELEMENT_TYPE  exceeds  that  value. 
For  example,  for  unconstrained  arrays  such  as  a  string  where  ELEMENT_TYPE'  SIZE  is 
very  large,  MAX_REC_SIZE  is  used  instead.  MAX_REC_SIZE  is  defined  in  system  as 
268_435_455  storage  units. 


Implementation-Dependent  Characteristics  of  SEQUENTIAL  I/O 

Instantiations  of  SEQUENTIAL_IO  use  the  value  max_rec_SIZE  as  the  record  size 
(expressed  in  STORAGE_UNiTs)  when  the  size  of  element_type  exceeds  that  value. 
For  example,  for  unconstrained  arrays  such  as  a  string  where  element_TYPE  '  SIZE  is 
very  large,  MAX_REC_SIZE  is  used  instead.  MAX_REC_SIZE  is  defined  in  SYSTEM  as 
268_435_455  storage  units. 


Form  Parameters 

The  HAPSE  implementation  of  the  standard  Ada  I/O  packages  support  form  parameters  of 
the  following  syntax  and  semantics  for  the  OPEN  and  CREATE  subprograms: 


O.'Jfl 
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form_parameters  :  :*•  [  formjpecification  {,  formjpecification}  ] 
form  specification  :  :  -  formjtame  ">  forms<due 

The  following  list  defines  the  supported  and 

Append  “>  True  1  False 

If  True,  the  file  is  opened  in  append  mode.  If  False,  the  file  will  be  opened  in 
truncate  mode,  which  is  the  default 

USE_ERROR  is  raised  if  specified  to  the  CREATE  subprogram. 


Owner  ->  read  1  write  |  execute  |  read_write  1  . . . 

Group  ->  read  |  write  I  execute  |  read_write  |  ... 

Other  »>  read  1  write  |  execute  |  read_write  |  ... 

The  file  being  created  will  have  the  permissions  as  defined  by  formjtame  and 
formjalue.  Notcthat.fom_vfl/Memay  beany  combination  of  read ,  write,  or 
execute,  separated  by  an  underscore  (e.g.,  wr  ite_read_execute). 

USE^ERROR  is  raised  if  specified  to  the  OPEN  subprogram. 


File_Descriptor  ->  n 

This  specifies  that  the  high  level  f  ile^type  be  associated  wifii  an  exiting  open 
file  descriptor,  as  specified  by  n.  n  should  be  of  a  form  consistent  with  inte 
ger'  image. 

USE_ERROR  is  raised  if  specified  to  the  CREATE  subprogram. 


Page_Terminators  ->  True  1  False 

If  False,  then  page  terminators  are  not  output  to  the  external  file.  If  ASCII .  FF  is 
encountered  while  reading  from  the  external  file,  it  is  interpreted  as  a  character 
ASCII  •  FF  and  not  as  a  page  terminator.  USE_ERR0R  will  be  raised  upon  explicit 
calls  to  TEXT^IO .  NEW_PAGE  or  to  TEXT_IO .  SET_LINE  when  the  current  line 
number  exceeds  the  specified  argument. 

If  True,  page  termination  on  output  will  result  in  ASCII .  FF  being  written  to  the 
external  file.  Encountering  ASCII .  FF  on  input  is  interpreted  as  a  new  page  (e.g., 
TEXT_IO .  GET  would  never  see  an  ASCII  •  FF  returned  to  it).  True  is  the  default. 


TerTtiinal_Input  =*>  Lines  1  Characters 

If  Lines,  terminal  input  shall  be  done  in  canonical  mode.  This  is  the  default. 

If  Characters,  terminal  input  shall  be  done  in  non-canonical  mode,  such  that  the 
fn^nimiim  input  count  is  1  character  and  the  minimum  input  time  is  0  seconds. 
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This  form  specificadon  has  no  effect  if  fee  associated  f  ile_type  is  not  used  for 
terminal  input 


Echo  ->  True  |  False 

If  True,  echoing  of  characters  is  done  on  input  operations  to  the  associated  terminal 
device.  This  is  fee  default 

If  False,  echoing  of  characters  is  not  done  on  input  operations  to  fee  associated 
terminal  device  for  non-canonical  processing.  USE_ERROR  is  raised  if  fee  non- 
canonical  processing  has  not  been  specified. 

File_Structure  =*>  Regular  |  Fifo 

If  Fifo,  then  fee  file  being  created  will  be  a  named  FIFO  file.  Otherwise,  the  file 
being  created  will  be  a  rcgularfile,  which  is  fee  default 

USE^ERROR  is  raised  if  specified  to  fee  OPEN  subprogram. 


Blocking  ->  Tasks  1  Program 

If  all  fee  in  fee  running  program  have  taskjveight  bound,  then  fee  form_valm 
must  be  Tasks;  otherwise,  USE_ERROR  is  raised. 

If  all  fee  tasks  in  fee  running  program  have  task_weight  MULTIPLEXED,  then  fee 
formj/alue  must  be  Prograun;  otherwise,  USE_ERROR  is  raised. 

If  fee  running  program  has  tasks  of  both  BOUND  and  MULTIPLEXED  task^weight^ 
then  ihtformji^alue  must  be  Program;  otherwise,  USE_ERROR  is  raised.  This  use 
of  Program  blocking  behavior  is  intended  to  indicate  that  if  a  task  blocks  while 
performing  I/O  on  the  associated  file,  other  tasks  in  the  program  may  be  blocked. 
The  actual  blocking  behavior  depends  on  fee  taskjveight  of  a  blocked  task. 


Machine-Code  Insertions 


WARNING 

It  is  not  recommended  practice  to  inline  machine-code  proce¬ 
dures,  as  the  compiler  does  not  track  register  uses  and  definitions 
made  by  machine-code  procedures.  Inlining  of  machine-code 
procedures  is  supported,  but  the  user  should  exercise  caution. 


Implementation-Dependent  Characteristics 


PowerPC-604  (Series  6000) 

The  general  definition  of  the  package  MACHINE_CODE  provides  an  assembly  language 
interface  for  the  target  machine  including  the  record  types  needed  in  the  code  statement, 
an  enumeration  type  containing  all  of  the  opcode  mnemonics,  a  set  of  register  defimtions, 
and  a  set  of  addressing  mode  functions.  Also  supplied  (for  use  only  in  umts  that  WITH 
MACHlNE_CODE)  is  the  implementation  defined  attribute  '  REF. 

Machine-code  statements  accept  operands  of  type  OPERAND, '  •,  private  type  that  forms  the 
basis  of  all  machine-code  address  formats  for  the  target 

The  general  syntax  for  a  machine-code  statement  is 

codeji'  {opcode,  operand  {,  operand]); 

In  the  following  example,  CODE_3  is  a  record  ‘format’  whose  first  argument  is  an  enu¬ 
meration  value  of  the  type  OPCODE  followed  by  three  operands  of  type  operand. 

code_3'  (ai,  r4  rA,  +1); 

The  opcode  must  be  an  enumeration  literal  (i.e.,  it  cannot  be  an  object,  an  attribute,  or  a 
rename).  Valid  opcodes  are  listed  in  “PowerPC-604  Instruction  Set”  on  page  9-31.  An 
operand  can  only  be  an  entity  defined  in  MACHINE_CODE. 

The  '  REF  attribute  denotes  die  effective  address  of  the  first  of  the  storage  units  allocated 
to  the  object  For  a  label,  it  refers  to  the  address  of  die  madiine  code  associated  with  the 
corresponding  body  or  statement  The  attribute  is  of  type  operand  defined  in  the  pack¬ 
age  MACHINE_CODE  and  is  allowed  only  within  a  machine  code  procedure.  '  REP  is  sup¬ 
ported  only  for  simple  objects  and  labels. 


PowerPC-604  Instruction  Set 

The  MACHlNE_CODE  package  supports  the  following  PowerPC-604  opcodes: 


add 

add_dot 

addc 

addcjdot 

addeo 

addco_dot 

adde 

adde_dot 

addeo 

addeo_dot 

addi 

addic 

addic_dot 

addis 

addme 

addme_dot 

addmeo 

addmeo_dot 

addo 

addo_dot 

addze 

addze_dot 

addzeo 

addzeo_dot 

and_dot 

and_r 

andc 

andc_dot 

andi_dot 

andis_dot 

b 

ba 

be 

bca 

beetr 

bcctrl 

bcl 

bcla 

bclr 

bclrl 

bctr 

bctrl 

bdnz 

bdnza 

bdnzeq 

bdnzeqa 

bdnzeql 

bdnzeqla 

bdnzeqlr 

bdnzeqlrl 

bdn2f 

bdnzfa 

bdnzfl 

bdnzfia 

bdnzflr 

bdnzflrl 

bdnzge 

bdnzgea 

bdnzgel 

bdnzgela 
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bdnzgelr 

bdnzgelrl 

bdnzgt 

bdnzgta 

bdnzgtl 

bdnzgtla 

bdnzgtlr 

bdnzgtlrl 

bdnzl 

bdozla 

bdozle 

bdnzlea 

bdnzlel 

bdnzlela 

bdnzlelr 

bdirdelri 

bdnzir 

bdnziri 

bdnzlt 

bdnzlta 

bdnzltl 

bdnzltla 

bdnzMr 

bdnzltlrl 

bdnzne 

bdnznea 

bdnznel 

bdnznela 

bdnznelr 

bdnznelrl 

bdii23ig 

bdnznga 

bdnzngl 

bdnzngla. 

bdnznglr 

bdnzngM 

bduznl 

bdnznla 

bdnznll 

bdnznlla 

bduznUr 

bdnznllrl 

bdnzns 

bdnznsa 

bdnznsi 

bdnznsla 

bdnznslr 

bdnznslrl 

bdnznu 

bdnznua 

bdnznul 

bdumula 

bdnznulr 

bdnznulrl 

bdnzso 

bdozsoa 

bdnzsol 

bdnzsola 

bdnzsolr 

bdnzsolrl 

bdnzt 

bdnzta 

bdnztl 

bdnztla 

bdnztlr 

bdnztlrl 

bdnzim 

bdnzuna 

bdnzunl 

bdnzunla 

bdnzunlr 

bdnzunlrl 

bdz 

bdza 

bdzeq 

bdzeqa 

bdzeql 

bdzeqla 

bdzeqlr 

bdzeqlil 

bdzf 

bdzfa 

bdzfl 

bdzfia 

bdzflr 

bdzflrl 

bdzge 

bdzgea 

bdzgel 

bdzgela 

bdzgelr 

bdzgelrl 

bdzgt 

bdzgta 

bdzgtl 

bdzgtla 

bdzgtlr 

bdzgtlrl 

bdzl 

bdzla 

bdzle 

bdzlea 

bdzlel 

bdzlela 

bdzlelr 

bdzielrl 

bdzlr 

bdzlrl 

bdzlt 

bdzlta 

bdzltl 

bdzltla 

bdzltlr 

bdzldrl 

bdzne 

bdznea 

bdznel 

bdznela 

bdzaelr 

bdznelrl 

bdzng 

bdznga 

bdzngl 

bdzngla 

bdznglr 

bdznglrl 

bdznl 

bdznla 

bdznll 

bdznlla 

bdznllr 

bdznllrl 

bdzns 

bdznsa 

bdznsl 

bdznsla 

bdznslr 

bdznslrl 

bdznu 

bdznua 

bdznul 

bdznula 

bdznulr 

bdznuM 

bdzso 

bdzsoa 

bdzsol 

bdzsola 

bdzsoLr 

bdzsolrl 

bdzt 

bdzta 

bdztl 

bdztla 

bdztlr 

bdztlrl 

bdzun 

bdzuna 

bdzunl 

bdzunla 

bdzunlr 

bdzimlrl 

beq 

beqa 

beqctr 

beqctrl 

beql 

beqla 

beqlr 

beqlrl 

bf 

bfa 

bfctr 

bfctrl 

bfl 

bfia 

bflr 

bflrl 

bge 

bgea 
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bgectr 

bgelrl 

bgtl 

bla 

blel 

blrl 

bid 

bnea 

bnelr 

bngctrl 

bnl 

bnlla 

bnsctr 

bnslrl 

bnul 

bsoa 

bsolr 

btetrl 

bun 

bunla 

clrlwi 

cmpi 

cmpw 

ciandc 

cmor 

crxor 

dcbtst 

divwo_dot 

eciwx 

exdwi 

extsbjdot 

fadd 

fcmpu 

fdiv 

fmadd_dot 

finsub 


bgectrl 

bgt 

bgda 

ble 

blela 

bit 

blda 

bnectr 

bnelrl 

bngl 

bnla 

bnllr 

bnsctrl 

bnu 

bnula 

bsoctr 

bsolrl 

bd 

buna 

bunlr 

clrlwi_dot 

cmpl 

cmpwi 

crclr 

cmot 

dcbf 

dcbz 

divwu 

ecowx 

exdwi_dot 

extsh 

fadd_dot 

fctiw 

fdiv_dot 

fmadds 

fmsub_dot 


bgel 

bgta 

bgdr 

blea 

blelr 

blta 

bldr 

bnectrl 

bng 

bngla 

bnlctr 

bnllrl 

bnsl 

bnua 

bnulr 

bsoctrl 

bt 

bda 

bunctr 

bunlrl 

clirwi 

cmpli 

cndzw 

creqv 

cror 

dcbi 

divw 

divwu_dot 

eieio 

extrwi 

extsh_dot 

fadds 

fctiw_dot 

fdivs 

fmadds_dot 

dnsubs 


bgela 

bgtctr 

bgtlrl 

blectr 

blelrl 

bltctr 

bltlrl 

bnel 

bnga 

bnglr 

bnlctrl 

bns 

bnsla 

bnuctr 

bnulrl 

bsol 

bta 

bdr 

bunctrl 

clrlslwi 

clirwi_dot 

cmplw 

cndzw_dot 

cnnove 

crorc 

dcbst 

divw_dot 

divwuo 

eqv 

extrwi_dot 

fabs 

fadds_dot 

fctiwz 

fdivs_dot 

finr 

finsubs_dot 


bgek 

bgtctrl 

bl 

blectrl 

blr 

bltctrl 

bne 

bnela 

bngctr 

bngM 

bnll 

bnsa 

bnslr 

bnuctrl 

bso 

bsola 

btctr 

btlrl 

bunl 

clrlslwi_dot 

cmp 

cmplwi 

crand 

cmand 

crset 

debt 

divwo 

divwuo_dot 

eqv_dot 

extsb 

fabs_dot 

fempo 

fctiwz_dot 

ftnadd 

fnir_dot 

fmul 
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£mul_dot 

finuls 

fmuis_dot 

&iabs 

&iabs_dot 

foeg 

fnegjdot 

&madd 

fiQinadd_dot 

fiomadds 

fiunadds_dot 

fiimsub 

fiimsubjot 

fnmsubs 

fimisubs_dot 

fres 

fres_dot 

£rsp 

frsp^dot 

firsqrte 

frsqrte_dot 

fsel 

fsel_dot 

fsqrt 

fsqrt_dot 

fsqits 

fsqrts_dot 

fsub 

fsub_dot 

fsubs 

fsubs_dot 

icbi 

inslwi 

inslwi^dot 

insrwi 

insrwi_dot 

isync 

Ibz 

Ibzu 

Ibzux 

Ibzx 

Ifd 

Ifdu 

Ifdux 

Ifdx 

Ifs 

Ifsu 

Ifsux 

Ifsx 

lha 

lhau 

Ibaux 

lhax 

Ihbrx 

Ihz 

Ihzu 

Ihzux 

Ihzx 

U 

lis 

Imw 

Iswi 

Iswx 

Iwarx 

Iwbrx 

Iwz 

Iwzu 

Iwzux 

Iwzx 

merf 

mcrfs 

mcrxr 

infer 

mfetr 

mfdar 

mfdbatl 

mfdbatu 

mfdec 

mfdsisr 

mfear 

mfifs 

iii£fs_dot 

mfibatl 

mfibatu 

mflr 

mfmsr 

mfpvT 

mfsdrl 

mfspr 

mfsprg 

mfsr 

mfsrin 

mfsrrO 

mfsrrl 

rnffb 

mftbl 

mftbu 

mftcer 

mr 

mterf 

mtctr 

mtdar 

mtdbatl 

mtdbatu 

mtdec 

mtdsisr 

mtear 

mtfsbO 

mtfsbO_dot 

mtfsbl 

mtfsbl_dot 

mtfsf 

mtfsf_dot 

mtfsfi 

mtfsfi^dot 

mtibatl 

mtibatu 

mtlr 

mtmsr 

mtsdrl 

mtspr 

mtsprg 

mtsr 

mtsrin 

mtsrrO 

mtsrrl 

mttb 

mttbu 

mtxer 

mulhw 

muihw_dot 

mulhwu 

mulhwu_dot 

mulli 

mullw 

mullw__dot 

mullwo 

mullwo_dot 

nand 

nand_dot 

neg 

neg^dot 

nego 

nego_dot 

nop 

nor 

nor_dot 

not_r 

not_dot 

or_dot 

or_r 

orc 

orc^dot 

ori 

oris 

rfi 

rlwimi 

rlwimi_dot 

rlwinm 

rlwinm^dot 

rlwnm 

rlwmn_dot 

rotlw 

rotlw_dot 

rotlwi 

rotlwi_dot 

rotrwi 

rotrwi_dot 

sc 

slw 

slw_dot 

slwi 

slwi_dot 

sraw 

sraw_dot 

srawi 

srawi_dot 

srw 

srw_dot 

srwi 
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srwi_dot 

stb 

stbu 

stbux 

stbx 

stfd 

stfdu 

stfdux 

stfdx 

stfiwx 

stfs 

stfsu 

stfsux 

st£sx 

sth 

sthbrx 

stbu 

sdiux 

sthx 

stmw 

stswi 

stswx 

stw 

stwbix 

stwcx_dot 

stwu 

stwux 

stwx 

sub 

sub_dot 

subc 

subc_dot 

subco 

subco_dot 

subf 

subf_dot 

subfe 

subfc_dot 

subfeo 

subfco_dot 

subfe 

subfe_dot 

subfeo 

subfeo_dot 

subfic 

subfine 

subfme_dot 

subfineo 

subfineo_dot 

subfo 

subfo_dot 

subfze 

subfze_dot 

subfeo 

subfzeo_dot 

subi 

subic 

subic_dot 

subis 

subo 

subo_dot 

sync 

tlbie 

tlbiex 

tlbsync 

trap 

tw 

tweq 

tweqi 

twge 

twgei 

twgt 

twgti 

twi 

twle 

twlei 

twlge 

twlgei 

twlgt 

twlgti 

twUe 

twUei 

twllt 

twllti 

twlng 

twlngi 

twlnl 

twlnli 

twit 

twlti 

twne 

twnei 

twng 

twngi 

twnl 

twnli 

xor_dot 

xor_r 

xori 

xoris 

Register  Set 


Registers  -  The  full  set  of  32  general-purpose  registers  for  the.PowerPC-604  architecture 
is  supported  (RO  through  R31),  plus  a  full  set  of  32  floating-point  registers  (FO  through 
F31),  8  control  registers  (CRFO  through  CRF7),  16  segment  registers  (SRO  through 
SR15),  and  44  special-purpose  registers  (XER,  LR,  CTR,  DSISR,  DAR,  DEC,  SDRl, 
SRRO,  SRRl,  SPRGO,  SPRGl,  SPRG2,  SPRG3,  ASR,  EAR,  TB,  TBU,  PVR,  IBATOU, 
IBATOL,  IBATIU,  IBATIL,  IBAT2n,  IBAT2L,  IBAT3a,  IBA,T3L,  DBATOU, 
DBATOL,  DBATIU,  DBATIL,  DBAT2U,  DBAT2L,  DBAT2L,  DBAT3D,  DBAT3L, 
MMC ,  RO,  PMCl,  PMC2,  SIA,  SDA,  HIDO,  lABR,  DABR,  PIR). 
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Addressing  Modes 

All  of  the  PowerPC-604  addressing  modes  are  supported  by  the  compiler.  They  are 
accessed  through  the  following  functions  provided  in  MACHINE_CODE. 


Address  Mode 

Assembler  Notation 

Ada  Function  Call 

External  Name 

lol6(Rame) 

extjo  (<name>) 

hil6(nume) 

ext_hi  {<nanu>) 

uhil6(Rame) 

label 

l0l4(<name>) 

label 

lo24(<name>) 

Absolute 

lol6(xia;) 

absoljo  (<dtsp>) 

hil6(xa:) 

absol_hi  i<disp>) 

uhil6(xxx) 

absol_uhi(<dtsp>) 

114 

lol4(<disp>) 

124 

lo24(<disp>) 

Register  Indirect 

0(Rn) 

indr  {<addr_reg>) 

with  Displacement 

I16(Rn) 

disp  i<reg>,<disp>) 

with  External 

lol6(namc)(Rn) 

lol6  {<ncme>,  <addr_reg>) 

Immediate  Data 

D,SI,UI 

“+”  (<mteger>) 

SI 

{<integer>) 

SI 

immed(<fntegcr>) 

Usage 


The  following  example  uses  machine  code  to  move  a  block  of  data. 

with  machtne_code; 
with  system; 

procedure  move  (dest,  src  ;  in  system. address;  length  :  in  positive)  is 
use  machine  code; 

pragma  implicit_code(of f ) ;  --  See  Section  9.3.4 
pragma  opt_flags  ( "noreorder" ) ; 


begin 

--  PowerPC -6 04  input  arguments  set  up  as: 
r3  <-  dest;  r4  <-  src;  r5  <-  length; 

--  save  CTR  in  r8  and  restore  it  before  returning 
code_2'  (mfspr,  r8,  CTR)  ; 
code_3'  (andil_dot,  rl ,  r5,  +3)  ; 

«backward_unaligned» 
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code_3'  (sriq,  r6,  r5,  iinmed(2) ) ; calculate  number  of  words 
oode_l'  (mtctr,  r6);  --  put  #  of  words  in  CTR 

--  checic  for  partial  word 
«bii_partlal» 

code_3'  (anpt,  crfO,  r7,  +0); 
code_2'  (ble,  crfO,  bu^loop ' r ef ) ; 

--  move  partial  word 
code_2'  (Ibzu,  r6,  di8p(r4,  -1)); 
code_2'  (stbu,  r6,  disp(r3,  -I)); 
code_3'  (ai#  r7,  r7,  -1); 
code_l '  ( b ,  bu_partial ' ref ) ; 

«bu_loop» 

code_3'  (Isi,  r6,  r4,  +4); 
code_3'  (ai#  r4,  r4,  -4); 
code_3'  (stsi,  r6,  r3,  +4); 
code_3'  (ai,  r3,  r3,  -4); 

code_l'  (bdn,  bu_loop ' ref ) ;  CTR  —  1;  b  if  /-  0 

«done» 

code.l'  (mtctr,  rS)  ;  --  restore  CTR 

code_0 '  ( op  “>  br ) ;  ^ “  Roturn . 


end  move? 


NOTE 

The  IMPLICIT_C0DE  pragma  is  used  to  optimize  the  code  by 
eliminating  the  stack  frame  and  the  copy  of  the  IN  parameters. 
The  br  instruction  is  necessary  when  the  IMPLICIT_C0DE 
pragma  is  utilized  to  act  as  the  return  statement 
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Overview 


Although  Chapter  9  discusses  all  pragmas,  it  focuses  on  pragmas  that  influence  the  soft- 
ware  development  environment,  compiling,  and  linking.  This  chapter  discusses  pragn^ 
that  affect  configuration  of  flie  whole  run-time  system,  task  execution,  and  memory  ut^- 
zation.  It  also  provides  some  information  about  the  underlying  implementation  of  tasking 
and  memory  resources. 


General  Pragmas 


The  following  pragmas  affect  the  run-time  system  as  a  whole. 


Pragma  RUNTIME.DIAGNOSTICS 

The  implementation-defined  pragma  runtimejiagnostics  controls  whether  or  not 
the  run-time  emits  warning  diagnostics. 

pragma  RUNTIME^DIAGNOSTICS  {boolean)  ; 

boolean  A  static  boolean  enumeration  literal.  TRUE  means  run-time  diagnostics 
will  be  emitted.  FALSE  means  run-time  diagnostics  will  not  be  emitted. 
The  default  is  TRUE.  At  run-time,  you  can  specify  this  value  via  a  call 
to  RUNTIME_CONFIGURATION .  SET_RUNTIME_D  I  AGNOSTICS. 


Pragma  MAP_FILE 

The  implementation-defined  pragma  MAP^FILE  may  occur  in  any  declarative  part.  It 
causes  a « Id  to  automatically  emit  at  link  time  a  map  ffle  containing  an  ASCII  description 
of  pragma  entries  and  comments  that  define  the  layout  of  the  file.  This  file  is  useful  in 
conjunction  with  the  a  .map  tool  defined  in  Chapter  5.  Similar  functionality  is  available 
via  a .  Id  -map.  If  this  pragma  is  absent,  then  no  map  file  will  be  produced. 

pragma  MAP_FILE  {filejiame)  ; 

file  name  A  static  string  of  non-zero  length  specifying  the  name  of  the  map  file. 
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Pragma  QUEUING_POLICY 

The  implementation-defined  pragma  QUEU1NG_P0LICY  sets  the  entry  queuing  policy, 
praqma  QUEUING_POLIcy  (poUcyJdentifier)  ; 

policyjdentifier  The  keyword  FIFO_QOEniNG  means  the  entry  queuing 
policy  as  defined  in  the  Ada  RM  sections  9.5.3  and  9.7.1. 
PRIORITY_QUEUING  means  the  entry  queuing  policy  as 
defined  in  Ada  95  RM  section  D.4.  The  default  is 
FIFO_QUEUING. 


Pragma  SERVER^CACHE^SIZE 


The  implementation-defined  pragma  SERVER_CACHE_SIZE  sets  the  size  of  the  server 
cache.  The  server  cache  contains  execution  servers  that  are  currently  unneeded  by  the 
application,  but  which  can  be  placed  back  into  service  when  they  become  necessary. 
These  include  the  anonymous  servers  for  terminated  BOUND  tasks,  as  well  as  servers  from 
server  groups  which  were  reduced  in  size  by  the  run-time. 

pragma  SERVER_CACHE_SIZE  {cache jize)  ; 

cache _size  A  static,  non-negative  number  specifying  the  maximum  number  of  serv¬ 
ers  allowed  in  the  cache  (i.e.,  the  server  cache  size).  The  default  is  8. 
This  value  can  also  be  set  at  run-time  via  a  call  to 
RtJNTIME_CONFIGURATION .  SET_SERVER_CACHE_SIZE. 


Pragma  DEFAULT_HARDNESS 

The  implementation-defined  pragma  DEFAaLT_HARDNESS  sets  the  default  hardness  for 
any  memory  bound  to  LOCAL  via  a  pragma  MEMORY_POOL.  It  can  be  overridden  by 
individual  MEMORY_POOL  pragmas.  See  “Pragma  MEMORY_POOL”  on  page  20-13. 

pragma  DEFAULT_HARDNESS  (hardness)  ; 

hardness  The  keyword  HARD  or  SOFT  specifying  the  default  hardness  for  mem¬ 
ory.  The  default  is  acquired  from  the  environment  at  program  start-up 
time. 

Note  that  when  a  Series  6000  system  is  configured  without  GLOBAL  memory,  the  operat¬ 
ing  systems  treats  LOCAL  memory  as  if  it  were  GLOBAL.  In  such  cases,  user  requests  to 
bind  virtual  memory  to  LOCAL  memory  will  be  rejected  since  the  system  considers  it 
GLOBAL. 
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Task  and  Group  Configuration  Concepts 

Task  Names  and  Default  Settings 


To  maVf  good  usc  of  task  pragmas,  it  is  necessary  to  understand  some  terminology. 
ENVIRONMENT  task 

At  start-up,  the  run-time  creates  this  one  task  that  performs  library-level 
package  elaboration  and  executes  the  main  program. 

DEFAULT  pseudo  task 

This  non-executing  pseudo  task  sometimes  provides  default  task- 
attribute  values  for  other  tasks.  The  user  may  change  these  default  val- 
ues  with  task  pragmas  or  with  calls  to  routines  in  package 

RtJNTIME_CONFIGURATION. 


ghost  task 

An  automatically  generated  overhead  task. 

For  any  actual  task  (excluding  objects  of  task  types)  or  ADMIN  or  TIMER  ghost  task,  if  a 
configuration  pragma  is  omitted  for  that  task,  the  value  specified  for  the  DEFAULT 
pseudo  task  is  used  instead. 

For  objects  of  task  types,  the  following  steps  indicate  the  search  order  for  configuration 
pragma  values. 

1.  If  the  object  is  a  variable  and  the  pragma  exists  for  that  variable,  that 
pragma  is  used. 

2.  If  the  pragma  exists  for  its  task  type,  that  pragma  is  used. 

3.  If  the  task  type  is  a  derived  type,  the  pragma  of  the  nearest  ancestor  type  is 

used  if  found. 

4.  If  no  such  pragma  is  found,  the  DEFAULT  pseudo  task  is  checked  for  the 
pragma,  and  diat  pragma  is  used  if  found. 

5.  If  no  pragma  has  been  found,  the  default  value  is  used. 

The  same  steps  take  place  simultaneously  for  SHADOW,  COURIER,  INTR_COURIER, 
and  PROXY  ghost  tasks. 


Task  Specifiers  in  Task  Pragmas 

The  following  task  specifiers  appear  in  task  pragmas.. 


taskjpecifier 

ordinaryjask 

ghostjask 


“  {or(Uruuy_task  I  ghostjask  I  ENVIRONMENT  I  SPEC} 
"  {task_type_name  I  task_yariable_name  I  DEFAULT} 

-  {companion_ghostjask  I  ADMIN  I  TIMER} 
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companionjshostjask 
shadow jhost 
covrierjhost 
irarj:ourier jhost 
proxyjhost 
task_entry 


{shadow _shost  I  courier  jhost  I  iTar_courierjhost  I  proxy_ghost} 

ordinary jask,  SHADOW;  taskjntry 

ordinaryjask,  COTOIEH,  taskjntry 

ordinaryjask,  lMTR_COXmiER,  taskjntry 

ordinaryjask,  PROXY 

{entry jtame  I  DEFAULT} 


taskjpecifier  Value 

Effect 

SPEC  or 
(omitted) 

The  pragma  must  occur  in  the  declarative  part  of  a  task  spec¬ 
ification.  It  then  appUes  to  all  tasks  identified  with  that  spec- 

ification. 

task  type 

The  pragma  s^plies  to  all  task  objects  of  that  task  type, 
regardless  of  where  the  task  objects  are  actually  declared. 

unless  overridden  for  derived  types  or  task  variables. 

task  variable 

TTie  pragma  must  appear  in  the  same  declarative  part  as  the 
declaration  of  the  task  variable.  In  this  case,  the  pragma 
affects  the  task  attribute  of  the  specified  task,  regardless  of 
any  other  task  pragmas  associated  with  defaults  or  task  spec¬ 

ifications. 

task 

The  pragma  applies  only  to  die  task  itself. 

DEFAULT 

The  pragma  sets  the  task  attribute  to  the  specified  value  for 
the  DEFAULT  pseudo  task,  and  therefore  for  all  tasks. 

emvibohment 

nniftRs  otherwise  specified  for  a  task. 

The  pragma  sets  the  task  attribute  to  the  specified  value  for 

the  ENVIRONMENT  task. 

ghost  task 

The  pragma  is  associated  with  the  specified  ghost  task. 

Ghost  task  specifiers  are  described  in  Chapter  17. 

Group  Names  and  Default  Settings 


To  make  good  use  of  group  pragmas,  it  is  necessary  to  understand  some  termmology. 


server  group 


Server  groups  allow  users  to  restrict  the  resources  their  tasks  use.  These 
groups  are  designated  by  simple  identifiers  and  are  defined  when  they 

are  used.  However,  they  are  not  Ada  program  entities,  Theycamot 

referenced  anywhere  except  within  the  appropriate  pragmas.  In  tact, 
they  exist  in  a  namespace  which  is  separate  from  the  Ada  languap  s 
namespaces.  This  separate  namespace  is  completely  flat.  That  is,  there 
is  no  hierarchical  nesting  to  the  namespace  based  on  the  umts  m  which 
these  pragmas  appear.  The  same  group  name  can  be  specified  m  two 
separate  and  unrelated  units,  and  it  will  indicate  the  same  group. 
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PREDEFINED  group  ^  j 

At  start-op,  the  run-time  creates  this  one  predefined  group  that  mchides 
and  executes  the  ENVIRONMENT  task.  By  default,  the  DEFAULT 
pseudo  task  is  also  in  this  group. 

DEFAULT  group  ,  r  u 

This  pseudo  group  provides  default  group-attribute  values  for  other 

groups  that  omit  any  group  configuration  pragmas.  The  user  may 
change  these  default  values  with  group  pragmas  or  witii  calls  to  routines 
in  package  runtime_configuration. 

To  add  to  any  group^  see  ‘Tragma  TASKJWEIGHT*  on  page  20-5. 


Group  Specifiers  in  Group  Pragmas 


The  following  server  group  specifiers  appear  in  group  pragmas. 

groupjpec  {DEFAUM  |  PREDEFINED  |  group jtame] 


group _spec  Value 

Effect 

DEFAULT 

The  pragma  sets  the  group  attribute  for  the  DEFAULT 
pseudo  group,  and  flierefore  for  all  groups,  to  the  specified 

value. 

PREDEFINED 

The  pragma  sets  the  group  attribute  for  the  PREDEFINED 
group  to  the  specified  value. 

group 

The  pragma  applies  only  to  die  group  itself. 

Task  Attributes 


Users  can  control  the  execution  of  tasks:  specifically,  tasks’  scheduling  priority,  time-slice 
duration,  physical  CTU  binding,  and  wei^t  Control  may  be  static  through  implementa¬ 
tion-defined  pragmas,  and  may  be  changed  dynamically  via  supplied  routines  m  the 
R0NTIME_C0NFIGURAT10N  package. 


Pragma  TASK_WEIGHT 

The  implementation-defined  pragma  TASK_WEIGHT  specifies  the  weight  of  a  task. 

?The  weight  of  a  task  specifies  whether  the  task  is  bound  to  a  server  or  if  it,  along  with 
some  set  of  other  tasks,  is  served  by  a  group  of  servers. 
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pragma  TASK^WEIGHT  (weight [,  taskjpedfier  ])  ; 


weight 

bound^spec 

muldplexedjpec 

passive jpec 

passivity 

general 

server 

ipl_server 


<  bound jpec  I  multiplexedjspec  I  passive  jpec  } 

BOUND 

MULTIPLEXED,  group^spec 
PASSIVE,  passivity 
{general  I  server  I  ipl^servery 
GENERAL 
SERVER 

IPL_SERVER,  iplj^alue 


There  are  three  possible  weights:  BOUND,  MULTIPLEXED,  and  PASSIVE. 

BOUND  taRVR  are  served  by  an  anonymous  group,  distinct  from  all  other  groups,  contain¬ 
ing  a  single  server. 

MULTIPLEXED  tasks  are  served  by  named  groups,  specified  by  groupjpec,  and  are 
associated  with  multiple  servers.  These  server  groups  are  configured  via  other  pragmas. 
(See  “Group  Attributes”  on  page  20-10.) 

PASSIVE  tasks  do  not  have  designated  servers  on  which  to  execute.  They  do  not  execute 
at  all  unless  called  via  an  entry  call.  When  they  ate  called,  the  server  executing  the  caller 
switches  to  execute  the  PASSIVE  task  and  continues  executing  the  passive  task  until  it 
blocks  waiting  for  another  entry  call.  It  then  resumes  execution  of  the  caller.  For  passive 
tasks,  the  passivity  must  also  be  specified. 

BOUND  tasks  can  be  thought  of  as  special-cases  of  the  MULTIPLEXED  case.  The 
sequence: 

pragma  TASK_WEIGHT  (BOUND,  t) ; 
is  roughly  equivalent  to: 

pragma  GROUP_SERVERS  (1,  anonjgroupjpec) ; 

pragma  TASK_WEIGHT  (MULTIPLEXED,  anon_groupjpec ,  t) ; 

The  weight  of  default  tasks  can  be  overridden  by  certain  options  to  the  a .  Id  tool. 

a. Id  -bound  overrides  as: 

pragma  TASK_WEIGHT  (BOUND,  DEFAULT); 

a .  Id  -multiplexed  overrides  as: 

pragma  TASK_WEIGHT ( MULTIPLEXED ,  PREDEFINED ,  DEFAULT ) ; 
pragma  GROUP_SERVERS ( 1 ,  PREDEFINED); 

In  the  absence  of  any  such  option  to  a .  Id,  by  default,  the  following  pragmas  apply: 

pragma  TASK_WEIGHT( MULTIPLEXED,  PREDEFINED,  DEFAULT); 
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In  otiier  woids,  by  default,  the  task  weight  for  aU  tasks,  including  the  environment  task,  is 
MULTIPLEXED. 

This  pragma  will  not  be  accepted  for  any  ghost  tasks.  SHADOW  ghost  tasks  have  no 
associated  weight  COURIER,  INTR.COURIER,  and  PROXY  ghost  tasks  are  always 
BOUND.  The  ADMIN  and  TIMER  ghost  tasks,  if  fliey  exist  are  always  BOUND. 

For  information  about  group  specifiers,  see  “Group  Specifiers  in  Group  Pragmas”  on  page 
20-5.  For  information  about  task  specifiers,  see  “Task  Specifiers  in  Task  Pragmas”  on 
page  20-3.  For  information  about  GENERAL,  IPL,  and  IPL_SERVER  tasks,  see  “Pas¬ 
sive  Tasks”  on  page  18-5. 


Pragma  TASK_PRIORITY 

As  discussed  in  the  chapters  relating  to  “task  scheduling”,  the  task  scheduling  priority  of  a. 
tagif  determines  how  the  Ada  run-time  selects  tasks  for  execution  withm  a  group.  Suni- 
larly,  the  operating  system  scheduling  priority  determines  how  the  real-time  kernel  selects 
task  groups  for  execution. 

The  implementation-defined  pragma  task.priority  is  primarily  used  to  set  the  task 
scheduling  priority.  For  a  BOUND  task,  it  also  sets  the  operating  system  scheduling  pri¬ 
ority  of  the  BOUND  task’s  anonymous  group.  See  “Task  Names  and  Default  Settings”  on 
page  20-2  to  find  out  how  a  task  without  an  explicit  pragma  TASK_PRI0RITY  setting 
gets  its  scheduling  priority. 

pragma  TASK_PRI0RITY  {_scheduling_priority  [ ,  taskjpecifier  ] )  ; 
scheduUngjjriority  { 

A  required  integer  expression,  possibly  a  program  variable,  specifying 
the  scheduling  priority.  It  is  in  the  range  0 .  .MAX_PRIORITY,  as 
defined  by  the  package  RnNTIME_CONFIGURATlON.  This  value  can 
also  be  set  at  run-time  via  a  call  to 

RUNTIME_CONFIGURATION . SET_TASK_PRIORITY 

Values  greater  than  MAX_PRI0RITY  will  be  truncated  to 
MAX_PRIORITY  by  the  run-time  executive. 

Values  less  than  0  are  considered  to  be  values  relative  to 
MAX_PRIORITY+l.  The  following  pragmas  are  equivalent 

pragma  TASK_PRIORlTY 

{ RUNTIME_CONFIGURATION . MAX_PRIORITY )  ; 

pragma  TASK_PRIORITY  ( ■ 1 )  ; 

As  previously  mentioned,  for  a  BOUND  task,  this  pragma  sets  the  operating  system 
scheduling  priority  of  the  BOUND  task’s  anonymous  group.  The  sequence: 

pragma  TASK_WEIGHT  (BOUND,  t)  ; 
pragma  TASK_PRIORITY  {prio,  t)  ; 

is  equivalent  to: 

pragma  GRODP_SERVERS  (1,  anon _group_spec)  ; 
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pragma  TASK_WEIGHT  (MULTIPLEXED,  anon_groupjpec ,  t)  ; 
pragma  GROUP_PRIORITY  {prio,  anonjroupjpec)  ; 
pragma  TASK_PRIORITY  {prio,  t); 

Unless  otherwise  specified,  the  default  value  of  scheduUngjriority  for  the  DEFALT 
pseudo  task  is  RUNTiME_C0NFiGnRATi0N .  PRiORiTY_OF_ENvpoNMENT.  Simi¬ 
larly,  oflierwise  specified,  the  default  value  of  scheduling _priority  for  the  ADMIN 

ghost  task  is  also  the  priority  of  the  environment 

Unless  otherwise  specified,  the  default  value  of  scheduling jriority  for  the  other  ghost 
tasks  is  as  follows: 


pragma  TASK_PRIORITY( DEFAULT, 
pragma  TASK_PRI0RITY( DEFAULT, 
pragma  TASK_PRIORITY( DEFAULT, 
pragma  TASK_PRIORITY( DEFAULT, 
pragma  TASK_PRIORITY( TIMER,  - 


SHADOW,  DEFAULT,  -1); 
COURIER ,  DEFAULT ,  - 1 ) ; 

INTR_COURIER,  DEFAULT,  -1); 
PROXY,  -1); 


For  information  about  task  specifiers,  see  “Task  Specifiers  in  Task  Pragmas”  on  page  20-3. 


Pragma  TASK_CPU_BIAS 

By  default  tasks  are  automatically  distributed  across  all  available  CPUs  on  the  system. 
However,  applications  are  also  provided  precise  control  over  task  distribution  with  the 
concept  of  &e  CPU  bias. 

A  CPU  bias  is  a  mask  in  which  the  relative  bit  number  identifies  a  CPU  #  (LSB  corre¬ 
sponds  to  CPU  #0).  For  example: 

CPU  Bias  Effect 

2#00000100#  Task  will  be  bound  to  CPU  #2 
2#01000010#  Task  allowed  to  execute  on  CPUs  #6  &  #1 
2#11111111#  Task  allowed  to  execute  on  all  8  CPUs 

Note  that  when  more  than  1  bit  is  set  in  a  CPU  bias,  the  kernel  will  continually  employ 
CPU  load-balancing  techniques  and  migrate  the  task  to  the  least  busy  CPU  specified  in  the 
bias. 

If  the  application  is  utilizing  physical  “local  memory”  pools,  the  kernel’s  load-balancing 
algorithms  will  not  automatically  migrate  tasks  to  CPUs  without  direct  access  to  those 
physical  pools.  However,  explicit  task  CPU  bias  specifications  will  allow  such  migration. 
See  “Pragma  MEMORY_POOL”  on  page  20-13  for  information  about  the  implementa¬ 
tion-defined  pragma,  MEMORY_pool,  and  physical  “local  memory”  utilization. 

NOTE 

Specifying  a  CPU  bias  of  zero  forces  the  task  to  use  the  “default 
task  bias”  as  described  below. 
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See  cpu_blas  ( 2 )  for  more  information  on  CPU  biases. 

The  implementation-defined  pragma  task_CPU_BIAS  provides  for  the  binding  of 
BOUND  tasks  to  individual  CPUs  or  a  set  of  CPUs,  associating  a  CPU  bias  with  one  or 
more  BOUND  tasks.  This  is  necessary  because  pragma  GROUP_CPa_BlAS  is  not  avail¬ 
able  for  BOUND  tasks.  See  ‘Task  Names  and  Default  Settings’’  on  page  20-2  to  find  out 
how  a  task  without  an  explicit  pragma  TASK_CPU_BIAS  setting  gets  its  CPU  bias. 

pragma  TASK_CPU_BIAS  (cpujfias  [,  taskjpecifier  ])  ; 

cpujias  A  required  CPU  bias,  possibly  a  program  variable,  specifying  CPUs  that 
are  valid  for  the  mnrhine  configuration  where  the  application  will  run. 
This  value  can  also  be  set  at  run-time  via  a  call  to 
RDNTIME_CONFIGURATION . SET_TASK_CPU_BIAS. 

By  default,  the  CPU  bias  for  all  tasks,  including  the  environment  task,  is  inherited  from 
the  bias  of  die  process  that  spawned  the  environment  task.  Normally  this  bias  specifies  all 
CPUs  on  the  system.  See  the  run(  1 )  system  command  for  more  details. 

The  sequence: 

pragma  TASK_WEIGHT  (BOUND,  t)  ; 
pragma  TASK_CPU_BIAS  (bias,  t)  ; 

is  equivalent  to: 

pragma  GROUP_SERVERS  (1,  anon_groupjpec)  ; 

pragma  TASK^WEIGHT  (MULTIPLEXED,  anon_groupjpec ,  t)  ; 

pragma  GROUP_CPU_BIAS  (bias,  anon_groiq}jpec)  ; 

For  information  about  task  specifiers,  see  “Task  Specifiers  in  Task  Pragmas”  on  page  20-3. 


Pragma  TASK.QUANTUM 

Apart  from  activatioii,  rendezvous,  abort,  delay,  termination,  and  priority,  task  scheduling 
is  also  dependent  on  its  time  slice.  A  task’s  time  slice  is  determined  by  its  quantum 
attribute.  A  quantum  is  the  length  of  time  a  task  actually  spends  executing  on  a  CPU.  As 
a  task  executes,  its  quantum  is  decremented  by  the  kernel  based  on  the  60Hz  system  clock 
interrupt  The  quantum  is  reset  when  it  is  decremented  to  zero.  At  this  time,  another  task 
may  be  scheduled  to  run  if  its  quantum  is  lower.  When  a  task  is  preempted  due  to  inter¬ 
rupts  or  higher  priority  tasks,  its  quantum  is  not  reset.  When  a  task  blocks  for  some  other 
reason  (rendezvous,  for  example)  its  quantum  is  reset  when  it  becomes  able  to  run. 

The  implementation-defined  pragma,  TASK^QUANTUM,  provides  for  the  specification  of  a 
task’s  quantum  value.  See  “Task  Names  and  Default  Settings”  on  page  20-2  to  find  out 
how  a  taxk  without  an  explicit  pragma  TASK_QUANTUM  setting  gets  its  CPU  quantum.  If 
the  default  task  quantum  for  the  DEFAULT  pseudo  task  has  not  been  explicitly  set  via  a 
TASK_QUANTUM  pragma,  then  the  task  gets  the  value  6. 

pragma  TASK_QUANTUM  {quantum  [,  taskjspecifier  ]  )  ; 
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quantum  A  non-zero  number,  possibly  a  program  variable,  of  60Hz  clock  ticks. 

The  value  can  be  set  at  run  time  via  a  call  to 

RUNTIME_CONFIGnRATION . SET_TASK_QUANTUM. 

By  default,  the  quantum  value  for  all  tasks  is  inherited  from  the  quantum  of  the  process 
that  spawned  the  environment  task.  Normally  this  value  is  the  system-wide  default  of  6. 
See  the  run  ( 1 )  system  command  for  more  details. 

For  information  about  task  specifiers,  see  ‘Task  Specifiers  in  Task  Pragmas”  on  page  20-3. 


Group  Attributes 


Users  can  control  the  operating  system  scheduling  priority,  physical  CPU  binding,  and 
number  of  servers  in  a  group.  Control  may  be  static  through  implementation-defined 
pragmas  or  through  the  run-time  configuration  package,  and  may  be  changed  dynamically 
via  supplied  routines  that  interface  to  the  run-time  executive. 


Pragma  GROUP.PRIORITY 


The  implementation-defined  pragma  GROUP_PRlORITY  specifies  the  operating-system 
scheduling  priority  of  all  the  servers  in  a  given  group.  It  does  not  specify  the  task  schedul¬ 
ing  priority  of  particular  tasks  within  the  group.  If  this  pragma  is  not  specified  for  a  par¬ 
ticular  group,  the  group  acquires  the  operating-system  scheduling  priority  of  the  environ¬ 
ment  that  spawned  it. 

pragma  GROUP_PRIORITY  (^scheduling priority ,  group_spec)  ; 
scheduling jmority 

A  static  integer  expression  specifying  the  operating  system  scheduling 
priority.  It  is  in  the  range  0 .  .  MAX_PRIORITY  as  defined  by  the  pack¬ 
age  RaNTIME_C0NFlGnRATI0N.  This  value  can  also  be  set  at  run¬ 
time  via  a  call  to 

RUNTIME_CONFIGURATION . SET_GROaP_PRIORITY. 

Values  greater  than  max_prI0RITY  will  be  truncated  to 
MAX_PRIORITY  by  the  run-time  executive. 

Values  less  than  0  are  considered  to  be  values  relative  to 
MAX_PRIORITY+l . 

For  information  about  group  specifiers,  see  “Group  Specifiers  in  Group  Pragmas  on  page 
20-5  . 
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Pragma  GROUP_CPU_BIAS 


The  implementation-defined  pragma  group_CPU_bias  specifies  the  CPU  bias  for  aU 
the  servers  in  a  given  group.  If  this  pragma  is  not  specified  for  a  particular  group,  the 
default  bias  is  acquired  from  file  environment,  which  indicates  any  CPUs. 

pragma  GROUP_CPa_BIAS  {cpuj)ias,  group jpec)  ; 

cpujms  A  static  CPU  bias  specifying  CPUs  that  ate  valid  for  the  machine  con¬ 
figuration  where  the  application  will  run.  At  run  time,  a  call  to 
RUNTIME_CONFIGURATION .  SET_GRODP_CPU_BIAS  can  be  used 
to  set  this  value. 

For  information  about  group  specifiers,  see  “Group  Specifiers  in  Group  Pragmas  on  page 
20-5. 


Pragma  GROUP_SERVERS 


The  implementation-defined  pragma  groop_SERVERS  controls  the  number  of  servers 
for  a  particular  group,  including  the  PREDEFINED  group. 

pragma  group_servers  {group^size,  group^spec) 

group  size  A  static  non-negative  number  indicating  the  guantity  of  servers  in  a 
group.  If,  for  any  group,  no  GROUP_SERVERS  pragma  is  specified, 
then  the  default  size  for  that  group  is  1.  At  run  time,  a  call  to 
RUNTIME_CONFIGURATION .  SET_GROUP_SERVERS  can  be  used  tO 
set  this  value. 

For  information  about  group  specifiers,  see  “Group  Specifiers  in  Group  Pragmas  on  page 
20-5. 


Specification  of  RUNTiME_CONFIGURATiON  Package 

?TODD 


Memory  Attributes 


On  Series  6000  systems  there  are  two  kinds  of  physical  memory  pools: 


•  Global  memory  (1  pool) 

•  Local  memory  (up  to  4  pools,  1  per  CPU  board) 
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An  example  configuration  of  a  6-processor  Series  6000  is  shown  in  Figure  20-1. 


SYSTEM  BUS 


CPU  CPU  CPU 

BOARD  A  BOARDS  BOARD  C 


CPU 

BOARD  D 


Figure  19-1.  Example  Configuration  for  6-Proces8or  Series  6000  System 

Global  memory  is  available  to  all  CPUs  via  a  system-wide  bus.  Local  memory  is  avail¬ 
able  to  CPUs  via  a  local  bus  physically  located  on  the  same  CPU  board  as  the  local  mem¬ 
ory.  Accessing  local  memory  from  a  foreign  board  CPU  is  allowed  but  is  extremely  costly 
and  should  be  prevented  in  all  time-critical  areas.  With  the  judicious  use  of  pragma 
MEMORY_POOL,  TASK_CPU_BIAS,  and  GROUP_CPU_BIAS,  an  Ada  application  can 
take  full  advantage  of  all  the  CPU  and  memory  resources  of  a  Series  6000  system. 


WARNING 

The  Iwarx  and  stwcx .  instructions  do  not  guarantee  indivisi¬ 
bility  of  operations  when  foreign  local  memory  is  involved;  do 
not  attempt  such  operations  with  data  structures  bound  to  foreign 
local  memory. 


NOTE 

The  HAPSE  package  INDIVISIBLE_OPERATIONS  in  bar- 
rislib  utilizes  the  Iwarx  and  stwcx .  instructions.  Do  not 
attempt  such  operations  with  data  structures  bound  to  foreign 
local  memory. 

Combining  local  memory  usage  with  hardware  interrupt  handling 
can  cause  erroneous  program  behavior  in  isolated  cases.  All  such 
cases  are  outlined  in  “Local  Memory  and  Hardware  Interrupts”  on 
page  21-8  dealing  with  hardware  interrupt  entries. 
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Pool  Specifiers 


The  following  memory  pool  specifiers  appear  in  memory  pool  pragmas. 

pooljpec  {text jwol  I  stack_pool  I  datajool  I 

collection jpool  I  defcadt_pool} 

sizeoble_spec  ""  {stack _pool  I  coUection_pool} 

paddable_spec  {stack _pool} 

defijult _pool  DEFADIiT 

text _pool  TEXT 

stack _pool  STACK,  {taskjpedfier} 

data _pool  DATA,  {PKG I  DEFAULT} 

collection jjool  COLLECTION,  {DEFAULT  I  accessjype} 


pooljspec 

This  parameter  specifies  the  particular  pool  of  memory 
whose  parameters  are  to  be  altered. 

DEFAULT 

This  value  the  memory _spec  is  applied  to  all  memory 

in  the  program  for  which  a  specific  memory  pool  was  not 
already  specified. 

TEXT 

For  the  entire  text  image  (machine  insttuctions),  specify  a 
value. 

STACK 

For  a  specific  task,  an  object  of  a  task  type,  the  environment 
task,  or  the  DEFAULT  pseudo  task,  the  stack  may  be  allo¬ 
cated  out  of  dynamic  pools  bound  to  local  or  global  mem¬ 
ory. 

In  this  form  the  pragma  may  occur  in  any  declarative  part 
If  the  second  parameter  is  ENVIRONMENT,  then  the  pragma 
affects  the  environment  task’s  stack.  If  the  second  parame¬ 
ter  is  SPEC,  then  the  pragma  must  be  immediately  enclosed 
by  a  specification  and  will  affect  all  associated  tasks.  If 

die  second  parameter  is  DEFAULT,  the  pragma  implies  to  all 
stack  fiames  for  all  tasks  not  marked  with  their  own  explicit 
pragma  MEMORY_POOL  specification.  If  the  second  param¬ 
eter  is  not  any  of  these  three  keywords,  then  it  must  be  the 
namft  of  a  task  type  or  a  task  variable  in  the  same  declara¬ 
tive  part 

DATA 

For  the  static  memory  associated  with  a  specific  package,  or 
for  all  other  packages,  specify  a  value. 

In  this  form  the  pragma  must  occur  in  the  immediate  declar¬ 
ative  part  of  a  library-level  package  specification,  a  library- 
level  package  body,  or  a  library-level  subprogram.  If  the 
second  parameter  is  PKG,  it  must  occur  in  the  package  spec¬ 
ification  or  body.  When  in  a  package  specification,  the 
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pragma  affects  all  static  data  for  the  package  specification 
and  for  the  package  body,  unless  another  pragma  is  applied 
to  the  body.  When  in  a  package  body,  the  pragma  affects  all 
static  data  for  the  package  body,  regardless  of  any  pragmas 
assoriatw<  with  the  package  specification.  When  the  second 
parameter  is  DEFAULT,  the  pragma  affects  all  other  static 

COLLECTION  For  the  memory  associated  with  an  access  type  with  a 

'  storage_size  clause,  specify  a  value.  When  a  pragma 
is  ^plied  to  a  COLLECTION,  that  collection  is  allocated 
fiom  heap  memory  and  can  never  be  deallocated.  It  is  rec¬ 
ommended  fliat  this  be  done  only  in  library-level  packages. 

In  tiiis  form  the  pragma  must  occur  in  the  same  declarative 
part  as  the  specification  of  the  supplied  access  jype.  The 
accessjype  must  have  a  '  storage_size  length  clause 
with  it  before  die  pragma  is  encoimtered. 


Pragma  MEMORY_POOL 


The  implementation-defined  pragma  MEMORY^POOL  is  used  to  change  physical  memory 
pool  attributes  from  their  default  values  for  a  memory  pool.  The  pragma  affects  the  map¬ 
ping  of  abstract  memory  to  physical  memory,  specifically:  static  data  (packages),  proce¬ 
dure  data  (stacks),  and  pointer  data  (collections). 

pragma  MEMORY^POOL  {pooljpec,  memory jpec)  ; 


memoryjpec 

globaljspec 

local_spec 

mp_cpuj?ias 

hardness 


{globaljspec  I  local jpec} 
GLOBAL 

LOCAL,  mp_cpu_bias  [,  hardness] 
{cpUjbias  I  HOME} 

{HARD  I  SOFT) 


pooljSpec 

memory jSpec 


GLOBAL 


See  “Pool  Specifiers”  on  page  20-13  for  more  information. 

specifies  new  values  for  memory  pool  attributes.  If  the 
MEMORY_POOL  pragma  is  not  specified  for  a  particular  pool 
(or  for  the  DEFAULT  pool),  the  default  value  for  the 
memory  spec  for  that  pool  depends  on  the  machine  configu¬ 
ration  on  which  it  runs.  For  a  system  with  a  single  CPU 
board,  its  value  is  the  value  specified  by  the  environment. 
For  a  system  with  multiple  CPU  boards,  its  value  is  GLO¬ 
BAL. 

’Uses  physical  global  memory.  Note  that  when  a  Series 
6000  system  is  configured  without  GLOBAL  memory,  the 
operating  systems  treats  LOCAL  memory  as  if  it  were 
GLOBAL.  In  such  cases,  user  requests  to  bind  virtual 
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memoiy  to  LOCAL  memory  will  be  rejected  since  the  sys¬ 
tem  considers  it  GLOBAL. 

LoCftli  Uses  physical  local  memory. 

cpujnas  Identifies  which  physical  local  memory  pool  to  utilize.  Dis¬ 

tinct  physical  local  memory  pools  are  identified  by  specify¬ 
ing  a  CPU  bias  which  contains  a  (partial)  list  of  CPU  num¬ 
bers  corresponding  to  a  CPU  board.  A  CPU  bias  is  a  mask 
in  which  the  relative  bit  number  identifies  a  CPU  #  (LSB 
corresponds  to  CPU  #0).  Refer  to  Figure  20-3.  Note  that 
the  cpujnas  must  specify  at  least  one  CPU  (cannot  be  zero). 
The  CPU_BIAS  is  used  to  locate  a  CPU  board’s  local  mem¬ 
ory  pool. 

The  cpu  bias  is  searched  starting  with  the  LSB  Geast  signif¬ 
icant  bitj  and  die  first  CPU  specified  by  the  bias  determines 
which  CPU  board  is  selected. 

For  example,  assume  that  a  user  provides  a  cpuj)ias  with 
bits  that  specified  CPUs  existing  on  two  different  CPU 
boards.  In  that  case,  the  CPU  board  selected  would  be  the 
board  that  holds  the  lowest  numbered  CPU. 

HOME  Allocates  the  memory  pool  from  the  LOCAL  memory  asso¬ 

ciated  with  the  CPU  on  which  the  appropriate  task  is  run¬ 
ning.  For  TEXT  and  DATA  memory  pools,  the  appropriate 
task  is  the  ENVIRONMENT  task  and  the  allocation  occurs 
before  the  ENVIRONMENT  task  executes  any  Ada  code. 
For  COLLECTION  memory  pools,  the  appropriate  task  is 
the  task  that  elaborates  the  access  type  associated  with  the 
memory  pool  and  the  allocation  occurs  at  the  time  of  that 
elaboration.  For  STACK  memory  pools,  the  appropriate 
tasif  is  the  one  that  will  be  using  the  stack  during  its  execu¬ 
tion,  the  allocation  occurs  when  that  task  is  created.  In 
any  of  these  cases,  if  a  task  migrates  to  another  CPU  after 
the  allocation  occurs,  the  memory  will  nol  also  migrate. 

hardness  Controls  usage  of  physical  global  memory  if  insufficient 

physical  local  memory  is  available.  The  default  value  for  an 
unspecified  hardness  is  defined  by  the 
DEFAaLT_HARDNESS  pragma. 

Figure  20-2  depicts  how  memory  mapping  might  occur  given  a  specific  configuration  and 
applications  of  pragma  memory_POOL. 


HAPSE  R^erence  McmmL 


SYSTEM  BUS 


Figure  19-2.  Memory  Usage  on  a  6*Processor  Series 
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cpu.biM  of  2«000001«a>CPU  BOARD  A 
cpu^blM  of  2i000010ta»CPU  BOARD  A 
cpu^blM  of  2f010000f«>CPU  BOARD  C 


Figure  19-3.  Relationship  of  cpu_blas  to  CPU  Board  on  a  6-Procossor  Series  6000  System 


For  memory  pools  associated  with  physical  local  memory,  the  pool  will  be  bound  to  the 
physical  local  memory  associated  with  the  highest  logical  CPU  number  fotmd  in  the  sup¬ 
plied  q)u_bias.  Since  it  is  possible  to  specify  a  cpu_bias  referencing  multiple  CPUs  not 
sharing  the  same  physical  local  memory,  the  preceding  algorithm  can  be  used  to  predict 
the  results.  Consider  the  following  example; 

1  package  defaults  is 

2  pragma  memory  pool  (data^  default,  global)  ; 

3  pragma  memory_pool  (stack,  environment,  global)  ; 

4  pragma  pool_size  (stack,  environment,  1024*1024)  ; 

5  pragma  pool_size  (stack,  default,  2048)  ; 

6  pragma  pool__3i2e  (collection,  default,  20*1024*1024)  ; 

7  pragma  memory  pool  (collection,  default,  global)  ; 

8  end  defaults  ; 

9 

10  package  aero  is 

11 

12  pragma  memory^pool  (data,  pkg,  local,  2#010000#,  hard,  ncache)  , 

13 

14  task  type  aeronautics  is 

15  pragma  task_weight  (bound,  spec)  ; 

16  pragma  task_cpu_jDias  (2 #010000#)  ; 

17  pragma  memory  pool  (stack,  spec,  local,  2#010000#)  ; 

18  end  aeronautics  ; 

19  for  aeronautics' storage_size  use  4096*8  ; 

20  end  aero  ; 

21 

22  package  eom  is 

23  task  equations  is 

24 

25  pragma  task_weight  (bound,  spec)  ; 

26  pragma  task_cpu_bias  (2 #000001#)  ; 

27  end  equations  ; 

28  end  eom  ; 
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In  the  preceding  example,  a  program  including  all  three  packages  would  have  these 
attributes,  assuming  the  machine  configuration  shown  in  Rguie  20-2: 

•  Static  data  is  allocated  out  of  global  memory  (line  2) 

•  The  environment  task’s  stack  frame  allocated  out  of  global  memory  (line 

3) 

•  The  size  of  the  environment  task’s  stack  firame  is  1  MB  (line  4) 

•  The  default  task  stack  frame  size  is  2  KB  (line  5) 

•  The  size  of  the  default  heap  is  20  MB  (line  6) 

•  The  default  heap  is  allocated  as  global  memory  (line  7) 

•  Static  data  for  package  aero  (both  for  specification  and  body)  is  allocated 
to  local  memory  on  CPU  board  C  (line  12)  (configuration-dependent) 

•  The  weight  of  tasks  of  type  aeronautics  is  BOUND  (line  15) 

•  Tasks  of  type  aeronautics  execute  on  CPU  #4  (line  16) 

•  Stacks  for  tasks  of  type  aeronautics  are  allocated  out  of  local  memory  on 
CPU  board  C  (line  17)  (configuration-dependent) 

•  The  stack  size  of  tasks  of  type  aeronautics  is  4  KB  (line  19) 

•  The  weight  of  task  equations  is  BOUND  (line  25) 

•  Task  equations  executes  on  CPU  #0  (line  26) 


Pragma  POOL_CACHE_MODE 


The  implementation-defined  pragma  POOL_CACHE_MODE  defines  the  cache  mode  for  a 
memory  pool. 

pragma  POOL_CACHE_MODE  {pooljpec,  cachejnode)  ; 

pooljpec  See  “Pool  Specifiers’’  on  page  20-13  for  more  information. 

cache  mode  The  keyword  COPYBACK  or  NCACHE.  COPYBACK  means 

use  the  operating  system’s  COPYBACK  cache  mode. 
NCACHE  means  use  the  operating  system’s  NCACHE  cache 
mode.  The  default  is  the  value  specified  for  the  DEFAULT 
pool.  If  there  is  no  DEFAULT  pool,  this  parameter  value  is 
COPYBACK. 

The  optional  cachejnode  sets  the  specified  system  cache  attribute  on  the  associated  mem¬ 
ory  pool  (see  the  system  service  memadvise  ( 2 )  for  more  information). 

In  COPYBACK  cache  mode,  only  a  single  task  is  usually  modifying  a  semi-private  data 
area  at  any  given  point  in  time  and  other  tasks  will  not  read  the  update  immediately.  This 
mode  does  not  cause  a  cache  flush  or  memory  bus  access  until  another  CPU  reads  the  data. 
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Pragma  POOL_LOCK_STATE 


The  implementation-defined  pragma  P00L_L0CK_STATE  defines  the  lock  state  of  a 
memory  pooL 

pragma  POOL_LOCK_STATE  {pooljpec,  lockjtate)  ; 

pooljpec  See  ‘Tool  Specifiers”  on  page  20-1 3  for  mote  information. 

lockjtate  The  keyword  LOCKED  or  UNLOCKED.  LOCKED  means  the 

memory  pages  ate  physically  locked  in  memory  and  cannot 
be  swapped  out  by  the  operating  system.  UNLOCKED 
means  die  memory  pages  can  be  swapped  out  by  the  operat¬ 
ing  system.  The  default  is  the  value  specified  for  the 
DEFAULT  pool.  It  there  is  no  DEFAULT  pool,  the  default  is 
UNLOCKED. 

If  a  program  specifies  that  text  is  to  be  locked  in  memory  and  local  memory  is  specified  by 
the  user  via  this  pragma,  then  task  migrations  to  foreign  CPU  boards  will  be  inhibited. 
Locking  occurs  when: 

•  FAST_INTERRUPT_TASKS  are  present 

•  plock  ( TXT_LOCK )  system  call  is  present 


WARNING 

When  locking  pages  in  memory  and  using  local  memory  pools 
and  using  hardware  interrupt  entries,  the  user  must  specify  addi¬ 
tional  information  to  the  hardware  interrupt  entry  address  clause. 
See  ‘‘Local  Memory  and  Hardware  Interrupts”  on  page  21-8. 


Pragma  POOL_SIZE 


The  implementation-defined  pragma  P00L_SIZE  permits  the  setting  of  the  size  for  a 
STACK  or  COLLECTION  memory  pool. 

pragma  POOL_SIZE  {sizeable jpec ,  sizejpec)  ; 

sizejpec  :  [size  \  UNLIMITED} 

sizeable  jpec  See  “Pool  Specifiers”  on  page  20-13  for  more  information. 

sizfi  A  static  non-negative  number  that  controls  the  amount  of 

Space  allocated  for  an  Ada  program’s  use. 

UNLIMITED  A  value  that  is  allowed  only  for  the  COLLECTION, 

DEFAULT  and  STACK,  ENVIRONMENT  memory  pools. 

This  pragma,  if  specified  for  the  STACK,  DEFAULT  pool,  will  not  affect  the  size  of  the 
STACK,  ENVIRONMENT  pool.  This  is  the  only  pragma  where  such  a  statement  is  true. 
The  implementation  is  this  way  so  that  the  stack  size  for  the  ENVIRONMENT  task  can  con- 
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riniw  to  be  UNIiIMITED,  which  is  its  default  value.  This  value  can  always  be  overridden 
explicitly,  though. 

If  fliis  pragma  is  not  specified  for  the  ENVIRONMENT  task’s  STACK  pool,  the  default  value 
is  ONlilMiTED.  If  this  pragma  is  not  specified  for  a  task  type’s  STACK  pool,  the  default 
value  is  the  task  type’s  '  storage_size  value  if  it  exists,  and  20480  otherwise.  If  no 
POOL_SIZE  pragma  is  valid  for  a  task  object  or  a  task  other  than  the  ENVIRONMENT 
task,  the  default  value  for  that  real  task  is  20480.  The  default  values  for  ghost  tasks  are  as 
follows: 


Table  20>1 .  Stack  Pool  Sizes  for  Ghost  Tasks 


Shadow  Type 

Default 

Stack  Size 

SHADOW 

N/A 

COURIER 

10240 

INTR_COURIER 

4096 

PROXY 

10240 

ADMIN 

12800 

TIMER 

12800 

If  this  pragma  is  unspecified  for  the  COLLECTION,  DEFAULT  pool,  its  value  is  unlim¬ 
ited.  If  this  pragma  is  unspecified  for  any  other  COLLECTION  pool,  then  its  default 
value  is  the  value  of  the  '  storage_si2e  attribute  for  the  collection. 


Pragma  POOL_PAD 


The  implementation-defined  pragma  pool_pad  sets  the  pad  for  a  STACK  memory  pool, 
pragma  POOL_PAD  {paddable^spec f  size)  ; 
paddablejspec  :  [stack_pool) 

size  A  non-negative  number  that  controls  the  amount  of  additional  pad  after 

the  stack  size.  This  value  has  no  meaning  when  the  stack  size  for  the 
same  pool  is  unlimited. 

This  additional  space  is  intended  only  for  use  by  the  run-time  system  or  for  signal  han¬ 
dlers.  For  ADMIN  ghost  tasks,  the  default  is  12800;  otherwise,  it  is  4096. 
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